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

Насколько я понимаю, существует четыре уровня хэширования, которые вы можете использовать в таблице паролей:

1. Нет – сохранить пароль в виде обычного текста. Если кто-то получает копию вашей базы данных, у них есть доступ ко всем учетным записям. Обычный текст плохой, «mkay?
2. Хешируйте пароль – сохраните хэш пароля и выбросьте реальный пароль. Если кто-то получает копию вашей базы данных, они не могут видеть никаких паролей, только хешей. Однако , если какие-либо пользователи используют слабые пароли, их хэши будут отображаться в радужных таблицах. Например, если у пользователя есть пароль «пароль», то хеш-память md5, хранящаяся в базе данных, будет «5f4dcc3b5aa765d61d8327deb882cf99». Если я посмотрю этот хэш в радужном столе, как на gromweb.com , он выплевывает «пароль».
3. Используйте значение соли – выберите большую случайную строку, такую ​​как GUID, и сохраните ее в файле конфигурации. Перед вычислением хэша добавьте эту строку к каждому паролю. Теперь радужный стол гораздо реже работает, потому что у него, вероятно, не будет записи для «password59fJepLkm6Gu5dDV» или «picard59fJepLkm6Gu5dDV». Хотя предварительно рассчитанные радужные столы не так эффективны, вы все равно можете быть восприимчивыми, если злоумышленник знает вашу соль. Злоумышленник может рассчитать хэш слабого пароля плюс соль и посмотреть, использует ли какой-либо пользователь в вашей базе данных этот слабый пароль. Если у вас несколько тысяч пользователей, то каждый хэш-расчет позволяет злоумышленнику сделать несколько тысяч сравнений. Как вы на самом деле используете соль, может зависеть от алгоритма шифрования, который вы используете. Для простоты просто представьте, что это добавляет соль и пароль вместе.
4. Используйте определенное значение соли – теперь вы берете что-то отличное от имени пользователя, адреса электронной почты или даже идентификатора пользователя и комбинируете это с паролем и большой случайной строкой из файла конфигурации перед вычислением хэша. Теперь злоумышленник, который знает вашу соль, все равно должен пересчитать хэш для каждого пользователя, чтобы узнать, использовали ли они слабый пароль, например «пароль».

Для получения более подробной информации посмотрите сообщение «Кодирование ужасов»: « Вероятно, вы неправильно храните пароли ».

Хотя для меня это кажется вполне достаточным, он будет в опасности, если кто-то предварительно вычислит таблицу радуги на основе того же алгоритма (что вполне возможно). Поэтому я предпочел бы использовать электронное письмо для соли, которое кажется довольно безопасным, но пригодным для использования. Параноиды могут добавлять некоторую постоянную соль на месте.

Люди часто делают слишком большую сделку из соли солярия (теоретически), в то время как в своих приложениях они допускают простые пароли и переносят их в обычном тексте по небезопасному HTTP на практике.

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

Единственная ваша проблема – сложность паролей.

Зачем? Позволь мне показать тебе.

экстраординарная хорошая соль + слабый пароль = разрыв в секундах

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

просто разумная соль + сильный пароль = нерушимый

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

Это не сильно влияет на атаки со словарями, только в два раза сложнее вычислять словарь по сравнению с одним md5 , а md5 в наши дни довольно дешев.

MD5 не является безопасным сам по себе, потому что он частично разбит (столкновения) и в любом случае слишком мал из дайджеста. Если вы не хотите использовать правильную функцию деривации пароля à la bcrypt, scrypt или PBKDF2, вы должны хотя бы использовать SHA-256 для новых проектов (и у вас есть план перехода на SHA-3, когда он будет отсутствовать, поэтому обязательно сохраните схему, которую вы использовали для хэширования пароля с результатом, поэтому обе схемы могут сосуществовать, когда вы используете новую процедуру хэширования, когда люди меняют пароли).

Если вы планируете продавать свою программу с использованием MD5 в любой емкости, это может быть показательный стоппер для большинства государственных продаж (например, в США используемые алгоритмы должны быть одобрены FIPS 140-2, а многие другие страны имеют одинаковые требования).

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

Если вы используете пароль как соль, злоумышленник может предварительно вычислить хэши $ word.md5 ($ word) сначала из своего словаря

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

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

Рассмотрим эту таблицу hashtable (с мнимыми хэшами, только для иллюстрации)

 word | hash ------------ foo | 54a64 bar | 3dhc5 baz | efef3 

Тестирование этих значений на вашем столе может быть таким же простым, как:

 SELECT h.word FROM hashtable h, yourtable y WHERE y.password = MD5( CONCAT( h.word, h.hash ) ); 

В матче у вас есть пароль.

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

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

Поэтому мой совет:

 md5( 'uniquesalt' . 'password' ); 

Или, вообще sha256 , не используйте md5 вообще, но используйте гораздо лучшие алгоритмы хэширования sha1 , sha256 (или выше).