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

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

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

    Очки 2, 3 и 4 по-прежнему заслуживают внимания.

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


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

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

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

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

    4. Не записывайте журналы, как «[AddUser] Hash of GeorgeBush: Rep4Lyfe: ASOIJNTY – это xyz”

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

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

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

    шаги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Так:

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

    • Key-stretching для замедления генерации хеширования. Вероятно, я поеду с PBKDF2.

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

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

    Оригинальный сентябрь 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] взломать с легко доступным комплектом [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

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

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

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

    Давайте будем гением компьютера.