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

Question

На этот вопрос уже есть ответ здесь:

• Безопасное хеширование паролей 9 ответов

Есть что-либо доступный, который нельзя тривиально сломать?

Answer 1

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

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

См. Сайт IT Security SE для большего.

---

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

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

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

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

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

Answer 2

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

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

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

Шаги:

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

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

Answer 3

В прошлом году у CodingHorror была отличная статья на эту тему.

http://www.codinghorror.com/blog/archives/000953.html

Рекомендация в конце статьи — BCrypt.

Answer 4

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

Однако существуют алгоритмы, специально созданные для извлечения ключей из паролей.Эти ключевые функции вывода.Они предназначены для использования с симметричными шифрами, но подходят и для хранения паролей. ПБКДФ2 например, использует соль, большое количество итераций и хорошую хэш-функцию.Если у вас есть библиотека, что ее реализует (например..NET), я думаю, вам стоит подумать об этом.

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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

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

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

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

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

Так:

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

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

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

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

Оригинал: сентябрь 2008 г. (оставлено, чтобы комментарии имели смысл)

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

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

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

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

Answer 11

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