Ответ 1

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

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

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

Подробнее см. сообщение "Кодирование ужасов", " Возможно, вы неправильно храните пароли.

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

С помощью предварительно вычисленного словаря, как следует из названия, кто-то уже заранее создал таблицу хэшей (вычисленный результат 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( 'uniquesalt' . 'password' );

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