Какой алгоритм мне следует использовать для хеширования паролей в мою базу данных?

Этот ответ 2008 года теперь опасно устарел. SHA (все варианты) теперь тривиально поддается взламыванию, и лучшая практика сейчас (по состоянию на январь 2013 года) заключается в использовании хэша растяжения ключа (например, PBKDF2) или в идеале - с интенсивным использованием ОЗУ (например, Bcrypt ), а также добавить соль для каждого пользователя.

На пункты 2, 3 и 4 все же стоит обратить внимание.

Дополнительную информацию см. На сайте IT Security SE.

Оригинальный ответ 2008 года:

1. Используйте проверенный алгоритм. SHA-256 использует 64 символа в базе данных, но с индексом в столбце, что не проблема, и это проверенный хэш, более надежный, чем MD5 и SHA-1. Он также реализован на большинстве языков как часть стандартного пакета безопасности. Однако не расстраивайтесь, если вы используете SHA-1.

2. Не просто хешируйте пароль, но и помещайте в него другую информацию. Вы часто используете хеш username: password: salt или аналогичный, а не просто пароль, но если вы поиграете с этим, то вам будет еще труднее запустить атаку по словарю.

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

4. Не пишите журналы вроде [AddUser] Hash of GeorgeBush: Rep4Lyfe: ASOIJNTY is xyz

Первое правило криптографии и хранения паролей - «не придумывайте сами», но если вы должны, вот абсолютный минимум, который вы должны сделать, чтобы иметь хоть какое-то подобие безопасности:

Кардинальные правила:

1. Никогда не храните пароль в виде обычного текста (что означает, что вы никогда не сможете его отображать или передавать).
2. Никогда не передавайте сохраненное представление пароля по незащищенной строке (простой текст, закодированный или хешированный).
3. Скорость - ваш враг.
4. Регулярно анализируйте и улучшайте свой процесс по мере улучшения оборудования и криптоанализа.
5. Криптография и процесс - это очень небольшая часть решения.
6. К точкам отказа относятся: хранилище, клиент, передача, обработка, пользователь, юридические гарантии, вторжение и администраторы.

Шаги:

1. Обеспечьте соблюдение разумных минимальных требований к паролю.
2. Часто меняйте пароли.
3. Используйте самый надежный хэш, который вы можете получить - здесь был предложен SHA-256.
4. Объедините пароль с фиксированной солью (то же самое для всей вашей базы данных).
5. Объедините результат предыдущего шага с уникальной солью (возможно, с именем пользователя, идентификатором записи, идентификатором, длинным случайным числом и т. Д.), Который сохраняется и прикрепляется к этой записи.
6. Выполните алгоритм хеширования несколько раз - более 1000 раз. В идеале каждый раз добавляйте к предыдущему хешу новую соль. Скорость - ваш враг, и несколько итераций снижают скорость. Время от времени удваиваются итерации (для этого требуется захват нового хэша - сделайте это в следующий раз, когда они изменят свой пароль).

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

В прошлом году CodingHorror опубликовал отличную статью на эту тему. Рекомендация в конце статьи: bcrypt.

Вышеупомянутые алгоритмы являются криптографически безопасными алгоритмами хеширования (но сегодня MD5 не считается безопасным).

Однако есть алгоритмы, специально созданные для извлечения ключей из паролей. Это функции вывода ключей. Они предназначены для использования с симметричными шифрами, но они также хороши для хранения пароля. PBKDF2, например, использует соль, большое количество итераций и хорошую хеш-функцию. Если у вас есть библиотека, то, что ее реализует (например, .NET), я думаю, вам следует ее рассмотреть.

Добавьте уникальную соль к хешированному значению пароля (сохраните значение соли в базе данных ). Когда используется уникальная соль. Преимущество использования более безопасного алгоритма, чем SHA1 или MD5, на самом деле не требуется (на этом этапе это постепенное улучшение, тогда как использование соли - монументальное улучшение).

Используйте сильную криптографическую хеш-функцию, такую ​​как MD5 или SHA1, но убедитесь, что вы используете хорошую соль, иначе вы будете уязвимы для атак радужной таблицы.

Обновление, январь 2013 г.

Первоначальный ответ датирован 2008 годом, и за последние 5 лет ситуация немного изменилась. Доступность облачных вычислений и мощных графических карт с параллельным процессором означает, что пароли длиной до 8 или 9 символов, хешированные как MD5 или SHA1, теперь можно легко взломать.

Теперь необходима длинная соль, как и что-то посложнее, например SHA512.

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

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

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

Растягивание клавиш - один из способов борьбы с этим. Алгоритм растягивания ключей (например, PBKDF2) применяет более быстрый хэш (например, SHA512) тысячи раз, что обычно приводит к генерации хеш-кода на 1/5 секунды или около того. Кто-то вошедший в систему не заметит, но если вы можете генерировать только 5 хэшей в секунду, атаки грубой силы будут намного сложнее.

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

So:

Какой алгоритм мне следует использовать для хеширования паролей в мою базу данных?

• Растягивание ключа для замедления генерации хэша. Я бы, наверное, выбрал PBKDF2.

• Соль для каждого пользователя означает новую атаку для каждого пользователя и некоторую работу по выяснению того, как ее получить.

Вычислительная мощность и доступность растут в геометрической прогрессии - скорее всего, эти правила снова изменятся через четыре года. Если вам нужна надежная защита в будущем, я бы исследовал хэши в стиле bcrypt / scrypt - они используют более медленные алгоритмы растягивания ключей и добавляют шаг, который использует много оперативной памяти для генерации хэша. Использование такого большого объема оперативной памяти снижает эффективность дешевых параллельных процессоров.

Исходный текст, сентябрь 2008 г. (оставлено так, чтобы комментарии имели смысл)

MD5 + соль или SHA1 + соль не «тривиально взломать» - большинство хаков зависят от огромных радужных таблиц, и они становятся менее полезными с солью [update, now they are].

MD5 + соль - относительно слабый вариант, но его нелегко сломать [update, now it is very easy to break].

SHA2 идет до 512 - это будет практически невозможно взломать с легкодоступным комплектом [update, pretty easy up to 9 char passwords now] - хотя я уверен, что где-то в каком-то военном бункере есть Cray, который может это сделать [You can now rent this 'Cray' from Amazon]

MD5 или SHA в сочетании со случайно сгенерированным значением соли для каждой записи

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

http://arstechnica.com/security/2012/08/passwords-under-assault/

поэтому используйте что-нибудь еще, например http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

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

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

Хеши MD5 / SHA1 - хороший выбор. MD5 немного слабее SHA1.