Может кто-нибудь объяснить, как соли помогают при хранении хешированных паролей? - PullRequest
7 голосов
/ 04 сентября 2010

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

Если соль есть, например, «привет» и добавляется к паролю «пароль», то соль и пароль хранятся вместе, «hellopassword» и хэшируются для получения:

94e66f94517d606d5ad6d9191b980408952f2ed2 (sha1) 

с добавленной солью:

hello$94e66f94517d606d5ad6d9191b980408952f2ed2

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

Ответы [ 3 ]

8 голосов
/ 04 сентября 2010

Нет, не с «небольшой дополнительной сложностью» - с потенциально значительно большей сложностью.

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

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

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

См. запись Википедии (если вы этого еще не сделали), чтобы узнать больше оэто.

6 голосов
/ 04 сентября 2010

Соль помогает двумя способами:

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

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

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

3 голосов
/ 04 сентября 2010

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

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