Хеширование и засоление поля пароля

Question

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

Сначала я прочитал о хешировании и посоле.Кажется, что идея в том, что ...

1. Получить алгоритм хеширования
2. Получить пароль от пользователя
3. Добавить 'соль' к обычному текстовому паролю от пользователя
4. хеширует весь пароль (включая соль)
5. Сохраните соль в БД, чтобы вы могли получить ее позже (для проверки PSWD)

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

Тогда у меня появилась идея.Что делать, если вы сохранили свою соль внутри поля хешированного пароля.Поэтому выполните шаги 1-4 (случайное создание соли), а затем на шаге 5 вставьте соль в пароль, известный как класс или служба интерпретации пароля:

xxxxxsaltvaluexxxxxxxxxxxxxxxx

, где x - этохешированные строковые значения.Кто-нибудь может увидеть какие-либо проблемы с этим?это просто совершенно ненужно?

Ответ:
Нет причин, по которым это невозможно сделать.Как утверждает Yahia, другие методы защиты пароля включают двойное (или n) хеширование.С другой стороны, BCrypt выглядит как хороший метод почти полного прекращения атак методом перебора, но я не смог найти доверенную библиотеку для C #

Спасибо!
TTD

Answer 1

С точки зрения безопасности, в которой нет необходимости, пока вы храните только хешированный пароль ( НИКОГДА не храните пароль в открытом виде!) Плюс соль ... злоумышленнику "разрешено" знать соль - ваша безопасность должна быть разработана таким образом, чтобы даже при знании соли она все еще была в безопасности.

Что делает соль?

Соль помогает в защите от атак грубой силой с использованием предварительно вычисленных «радужных таблиц».Соль делает грубую силу намного дороже (в терминах времени и памяти) для атакующего.Вычисление такой таблицы является дорогостоящим и обычно выполняется только тогда, когда его можно использовать для более чем одной атаки / пароля.Если вы используете одну и ту же соль для всех паролей, злоумышленник может предварительно вычислить такую ​​таблицу, а затем переборить ваши пароли в открытый текст ...Пока вы генерируете новую (лучшую криптографически стойкую) случайную соль для каждого пароля, для которого вы хотите сохранить хеш, проблем не возникает.

Что касается вашей идеи "замаскировать" соль Это в большей степени «безопасность от неясности» , которой следует избегать.Хотя в этом случае я не вижу ни положительного, ни отрицательного эффекта.

Если вы хотите еще больше укрепить безопасность Вы можете вычислить хэш несколько раз (хэш и т. Д.) - это не будет стоить вам дорого, но делает атаку грубой силой / вычисление «радужных таблиц» еще дороже ... пожалуйста, не изобретайте себя- существуют проверенные стандартные методы для этого, см., например, http://en.wikipedia.org/wiki/PBKDF2 и http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Answer 2

Вы собираетесь упасть в кроличью нору. Использовать bcrypt .

Answer 3

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

Если вы используете Salting, вы повысите безопасность, сохранив Salt и значение Hash, которому оно принадлежит, конечное значение рассчитывается с использованием сгенерированной солив сочетании с паролем, из которого было вычислено значение хеша, пароль не сохраняется в вашей базе данных, а только вычисленное значение хеша, это означает evtl.Хакер не может ничего сделать, имея только значение Hash и Salt.

Read this