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

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

ОТВЕТЫ

Ответ 1

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

Баллы 2, 3 и 4 все еще стоит обратить внимание.

Подробнее см. сайт IT Security SE.

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

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

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

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

  • Не записывайте журналы типа "[AddUser] Hash of GeorgeBush: Rep4Lyfe: ASOIJNTY is xyz"

Ответ 2

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

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

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

Шаги:

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

Обновление в январе 2013 года

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

Теперь длинная соль является обязательной, как и нечто более жесткое, как SHA512.

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

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

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

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

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

Итак:

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

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

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

Вычислительная мощность и доступность растут экспоненциально - скорее всего, эти правила снова изменятся еще через 4 года. Если вам нужна надежная защита, я бы изучил хэширование стиля 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]

Ответ 8

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

Ответ 10

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

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

Ответ 11

Хеши MD5/SHA1 являются хорошим выбором. MD5 немного слабее, чем SHA1.