Если я создаю логин для приложения со средним или низким уровнем безопасности (другими словами, это не банковское приложение или что-то еще), могу ли я подтвердить пароль, введенный пользователем, просто сказав что-то вроде:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

Кажется, легко быть эффективным, но я, конечно, не возражал бы, если бы это было все, что требовалось. Достаточно ли простой проверки на имя пользователя и пароль?

Обновление: конкретным проектом является веб-служба, проверка выполняется исключительно на стороне сервера и не является открытым исходным кодом. Меняется ли домен, как бы вы справились с этим?

Не без SSL

Это небезопасно, если пароль передается по сети в виде простого текста. Хеширование пароля на стороне сервера также небезопасно, если пароль передается по сети в виде простого текста.

Поскольку <input type="password"/>тег HTML отправляет свое содержимое в виде простого текста, это будет проблемой независимо от того, как вы храните пароль на сервере, если только ваш сайт не использует SSL для передачи пароля.

(HTTP-аутентификация, при которой в браузере появляется диалоговое окно с запросом пароля, может быть или не быть простым текстом, в зависимости от того, какие общие механизмы аутентификации используются у сервера и браузера. Так что это может быть способом избежать этого без использования SSL).

Нет, если администраторы сайта подозревают

Теперь, предположим, что вы используете HTTPS для создания веб-сайта, это может быть безопасно, если вы доверяете своим администраторам сайта (которые могут читать простые текстовые пароли) и другим людям, имеющим доступ к компьютеру, вести себя должным образом. Теперь может быть очевидно, что они могут делать с вашим сайтом все, что захотят (так как они его администрируют), но если они смогут прочитать пароль, они также смогут использовать украденные пары логин / пароль на сайтах других людей.

Способ защиты паролей от администратора

Один безопасный способ хранения и проверки паролей заключается в следующем:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

Для хэш-функции попробуйте использовать что-то сильное и то, что еще не имеет хороших радужных таблиц в дикой природе. Вы можете изменить длину соли, если необходимо, обойти радужные столы.

В зависимости от среды, в которой вы находитесь, изменчивости задержки в вашей сети и того, должны ли имена пользователей быть общедоступными, вам может потребоваться вычислить другой путь к коду, hash('0000'+entered_password)если пользователя не существует, чтобы не дать злоумышленникам определение того, какие имена пользователей являются действительными, на основе времени, которое требуется, определите, что пароль является неправильным.

Это говорит о том, что вы храните пароли в открытом тексте, что нельзя, даже в сценариях с низким уровнем безопасности.

Вы должны иметь:

if(hash(enteredPassword) == storedHash)

Вы можете использовать простой хеш, как, например, MD5

Я согласен с теми, кто предлагает хеширование, но есть и колесо, которое вы здесь изобретаете. В зависимости от платформы вы, вероятно, сможете найти инструмент управления ролями / пользователями, который безопасно и надежно охватывает все элементы управления пользователями, не требуя слишком большого вмешательства с вашей стороны.

Безопасность - очень деликатный вопрос, особенно потому, что необходимо соблюдать баланс между неудобством для ваших пользователей и обеспечением безопасности их информации. Как правило, формула того, какой уровень безопасности вам нужен, зависит от важности данных. Короче говоря:

isSecuritySufficient = effortToBreak > rewardForBreaking

Распространенное заблуждение о людях, которые делают плохие вещи, - то, что они ищут Большинство из них стремится разрушить доверие . Вы всегда должны делать все возможное, чтобы защитить доверие своих пользователей. Частью этого является ваша должная осмотрительность, чтобы убедиться, что их личность в безопасности. Они могут меньше заботиться о данных, которые они хранят, но они заботятся о своей идентичности - даже при самом низком пороге безопасности.

Существует ряд недорогих (для реализации и воздействия на пользователя) вариантов. Одним из них является хеширование пароля как минимум. Любой сервис, который хранит что-то такое же чувствительное, как пароль, в виде простого текста, заслуживает того, чтобы его взломали.

Общие принципы защиты паролем

• Никогда не храните пароли в виде простого текста
• Хеширование с использованием безопасной хеш-функции, такой как SHA-1 или даже SHA-512 (даже MD5 слишком легко найти подходящий хеш)
• Используйте значение соли приложения. Соль - это случайные байты, которые либо добавляются к паролю, чтобы его было сложнее угадать. Соль должна генерироваться во время выполнения и использовать информацию о машине в качестве начального значения, а не храниться и ссылаться каким-либо образом.
• Используйте специфическое для пользователя значение соли. Используйте это в сочетании с солью вашего приложения.
• Зашифруйте все запросы аутентификации, которые идут по сети. Это означает использование SSL для веб-приложений.

Поскольку вы будете использовать SSL для аутентификации, как минимум, вы хотите зашифровать все страницы, которые также относятся к учетной записи пользователя. Это позволяет максимально защитить личность пользователя.

Примечание об управлении паролями : пользователи будут время от времени забывать свой пароль. Самое худшее, что вы можете сделать, это отправить им пароль по электронной почте. Если вы реализуете принципы, изложенные выше, вы все равно не сможете этого сделать. Гораздо лучше предоставить способ сброса пароля, используя ссылку, отправленную на зарегистрированный адрес электронной почты. Эта ссылка для сброса будет иметь одноразовый код, чтобы гарантировать, что доступ к странице принадлежит им.

Это нормально, если пароль не используется ни для чего другого. Все еще существует риск, что пользователь решит, что он может повторно использовать пароль, поэтому было бы еще лучше с:

if(hash(enteredPassword) == hashOfValidPassword)

Если это для вас или кого-то, кто знает, что пароль хранится в виде простого текста, то это нормально.

Доступен ли исходный код? Даже если нет, я вполне уверен, что пароль может быть найден в машинных инструкциях, если бинарный файл доступен. Я бы рекомендовал сделать контрольную сумму и сравнить ее.

Никогда не забывайте о безопасности, даже если это не очень важно по вашему мнению.

Точно нет. Прочитайте это , оно описывает, как хакеры взломали сайт безопасности. Вы планируете сделать вас самым слабым звеном в цепи.

В нескольких ответах было отмечено, что вы должны хранить не сам пароль, а хеш - и вам следует использовать SSL.

Вы можете сказать, в чем дело? Если мое приложение будет взломано, это не будет проблемой. Ну, это довольно распространенный шаблон для пользователей повторно использовать один и тот же пароль на всех сайтах. Если бы хакер взломал ваш сайт и получил доступ к паролям пользователей, он мог бы выдать себя за многих из этих пользователей на других сайтах, более важных для этих пользователей. Так что взлом вашего сайта может стать первым шагом для хакера, чтобы получить доступ к банковской информации для пользователей.

И простого хеширования пароля недостаточно. Вы должны смешать это с солью. Хакеры имеют таблицы обратного просмотра хэша, поэтому для данного хэша они могут найти соответствующий пароль.

Если вы решите не реализовывать эту функцию, вы должны проинформировать пользователей об этом недостатке безопасности, поощряя их не использовать тот же пароль, который они используют в другом месте.

Пока это на стороне сервера .. Тогда да.

Если вы хотите немного больше безопасности, зайдите на https и зашифруйте \ хэшируйте пароль в БД.