T-SQL AES Encryption vs Hashing / Salting для входа пользователей на сайт

Question

У меня есть проект, и, очевидно, разработчики программного обеспечения не приняли во внимание безопасность.

Пароли хранятся в виде простого текста и передаются в виде простого текста. Так что мне остается задача исправить это.

Я немного обеспокоен безопасностью, поэтому мой вопрос таков: для онлайн-аутентификации по паролю пользователя лучше использовать методы хеширования / посола или лучше использовать шифрование AES? Могу ли я иметь плюсы и минусы.

Было бы лучше как-нибудь использовать поставщика членства ASP.NET? Будет ли это легко сделать? Я использовал это раньше, но программное обеспечение вызывает свои собственные таблицы, так что я не уверен, что там больше проблем.

Если бы на этот вопрос ответили, кто-нибудь мог бы направить меня туда, потому что я не нашел сравнения.

Answer 1

Вы НИКОГДА не должны хранить пароли, используя симметричное шифрование.

Произвольная соль для каждого пользователя, хэшируйте их пароль, сохраняйте соль и хэш в базе данных.Затем по запросам на вход в систему вы получаете пользователя по электронной почте / username / id и т. Д., Затем используете соль, привязанную к этому пользователю, и хешируете предоставленный им пароль, а затем сопоставляете его с сохраненным хешем.Если совпадает, войдите, иначе неверный пароль.

Если вы используете встроенный поставщик членства ASP.NET, он должен сделать это для вас.

Answer 2

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

Будет немного неприятности, если вы поддержите возможность изменять имена пользователей.Изменение имени пользователя может создать дыру в безопасности, если не сделать это осторожно, так как членство зависит от имен пользователей и идентификаторов пользователей таким образом, что это может привести к дырам (хотя для этого требуется, чтобы не злонамеренный пользователь изменил свое имя, поэтому это не большая дыра).

Answer 3

Я предлагаю вам многократно хешировать соленый пароль. Более 10 раз или что-то. Так почему же? Потому что для вас хэширование соленого пароля не займет заметно больше времени. Но для злого парня, пытающегося использовать разные комбинации для взлома пароля, каждая попытка занимает в 10 раз больше времени. И он не может быть уверен, сделал ли ты это 10 или 1000 раз.

Я использую это лично как дешевое повышение безопасности.

Смотрите здесь: Stackoverflow Salting Ваш пароль: лучшие практики?

или там Безопасный хеш и соль для паролей PHP

Удачи:)

Harry

Answer 4

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

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