Зачем хранить соль вместе с хешированным паролем в базе данных - PullRequest
0 голосов
/ 22 мая 2018

В настоящее время я работаю в системе, где мне нужно хранить хешированный пароль.Я использую cryptographically secure pseudo-random number generator (CSPRNG) для генерации salt.Я использую PBKDF2 для хеширования пароля, добавленного к salt, который в итоге будет сохранен в базе данных.

То, что я не получаю, это то, почему мне даже нужно хранить salt вместе с hashed password в базе данных.Я понимаю цель salt.Это значительно снижает вероятность успешных атак rainbow and lookup.Также пользователи с одним и тем же паролем будут иметь разные хэши, хранящиеся в базе данных.

Так откуда же нужно хранить соль в базе данных?

ОБНОВЛЕНИЕ:

Я должен был упомянуть об этом раньше, но в тот раз он не щелкнул меня.password здесь никогда не будет предоставлен пользователем.Это для наших внутренних целей.Нам просто нужно, чтобы он был сгенерирован в первый раз, когда пользователь заходит на наш сайт, и позже мы просто отправим этот Hashed пароль в ответе.

Ответы [ 2 ]

0 голосов
/ 22 мая 2018

Что если мы не солим?

Вы уже понимаете, что если вы используете Password1 самостоятельно (без соли), то каждый раз, когда вы его хешируете, вы получите точноетот же результат.Теперь давайте представим, что у вас 1000 пользователей, и из этих 1000 25 используют один и тот же пароль.Эти 25 хэшей будут точно такими же .Как только злоумышленник получит доступ к вашей базе данных и обнаружит, что хэш 70ccd9007338d6d81dd3b6271621b9cf9a97ea00 преобразуется в Password1, он получит доступ к учетным записям 25 пользователей в кратчайшие сроки.Это означает, что атака с помощью радужного стола позволит ему быстрее получить доступ к большему количеству учетных записей.

Что, если мы будем использовать соль?

Добавив соль к значению Password1, вы получите драматическиизменить хэш.У каждого пользователя должна быть своя соль.Это означает, что даже если все 1000 ваших пользователей используют Password1, все 1000 хешей будут совершенно разными.В реальном мире это означает, что 25 из 1000 пользователей с одинаковым точным паролем будут иметь разные хэши.Тем не менее, это также означает, что злоумышленнику придется запускать атаку по одному паролю за раз, а не просто радугу собирать хеш-коды и надеяться на лучшее.

Но почему мы храним соль?

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

Надеюсь, это объясняет немного лучше, и, как всегда, если у вас есть какие-либо комментарии, не стесняйтесь спрашивать

0 голосов
/ 22 мая 2018

Выход PBKDF2 зависит от соли.Если вы не храните соль, то вы не сможете определить, верен ли пароль.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...