Является ли «двойное хеширование» пароля менее безопасным, чем одноразовое хеширование? - PullRequest
282 голосов
/ 08 декабря 2008

Хеширование пароля дважды перед хранением более или менее безопасно, чем простое хеширование?

То, о чем я говорю, делает это:

$hashed_password = hash(hash($plaintext_password));

вместо этого:

$hashed_password = hash($plaintext_password);

Если это менее безопасно, можете ли вы дать хорошее объяснение (или ссылку на него)?

Кроме того, имеет ли значение хеш-функция? Имеет ли какое-то значение, если вы смешаете md5 и sha1 (например) вместо того, чтобы повторять одну и ту же хеш-функцию?

Примечание 1: Когда я говорю «двойное хеширование», я говорю о хешировании пароля дважды, чтобы сделать его более скрытым. Я не говорю о технике разрешения коллизий .

Примечание 2: я знаю, что мне нужно добавить случайную соль, чтобы действительно обеспечить ее безопасность. Вопрос в том, помогает ли хеширование дважды с помощью одного и того же алгоритма или вредит хешу.

Ответы [ 16 ]

1 голос
/ 08 декабря 2008

Как показывают несколько ответов в этой статье, в некоторых случаях это может повысить безопасность, а в других - когда это явно вредит. Есть лучшее решение, которое определенно улучшит безопасность. Вместо того, чтобы удваивать количество раз, которое вы вычисляете хеш, удваивайте размер вашей соли, или удваивайте количество бит, используемых в хэше, или делайте оба! Вместо SHA-245 прыгайте на SHA-512.

1 голос
/ 08 декабря 2008

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

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

Это защищает от атак по словарю, таких как «обратные базы данных MD5», но также и от соления.

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

0 голосов
/ 31 августа 2012

Да.

Абсолютно не использовать несколько итераций обычной хеш-функции, например md5(md5(md5(password))). При best вы получите незначительное повышение безопасности (подобная схема практически не защищает от атаки с помощью графического процессора; просто передайте ее по конвейеру.) В худшем случае вы уменьшаете свое хэш-пространство (и, следовательно, безопасность ) с каждой добавленной вами итерацией. В области безопасности целесообразно предполагать худшее.

Используйте пароль, который был разработан компетентным криптографом для эффективного хеширования пароля и устойчив к атакам с использованием грубой силы и пространственно-временных атак. К ним относятся bcrypt, scrypt и, в некоторых случаях, PBKDF2. Хеш на основе glibc SHA-256 также приемлем.

0 голосов
/ 08 декабря 2008

Двойное хэширование ужасно, потому что, скорее всего, злоумышленник построил таблицу, чтобы получить большинство хэшей. Лучше солить свои хеши и смешивать их вместе. Существуют также новые схемы для «подписывания» хэшей (в основном, соляных), но более безопасным способом.

0 голосов
/ 08 декабря 2008

Забота об уменьшении пространства поиска является математически правильной, хотя область поиска остается достаточно большой, что для всех практических целей (при условии, что вы используете соли), при 2 ^ 128. Однако, поскольку мы говорим о паролях, число возможных 16-символьных строк (буквенно-цифровые, заглавные буквы, несколько символов, добавленных) составляет примерно 2 ^ 98, согласно моим подсчетам за пределами конверта. Таким образом, воспринимаемое уменьшение в пространстве поиска не очень актуально.

Помимо этого, на самом деле нет никакой разницы, если говорить криптографически.

Хотя существует криптографический примитив, называемый «цепочкой хэшей» - методика, которая позволяет вам делать некоторые интересные трюки, такие как раскрытие ключа подписи после его использования, без ущерба для целостности системы - учитывая минимальное время Синхронизация, это позволяет вам обойти проблему первоначального распределения ключей. По сути, вы предварительно вычисляете большой набор хэшей хэшей - h (h (h (h .... (h (k)) ...))), используйте n-ное значение для подписи, после установленного интервала вы отправляете ключ и подпишите его, используя ключ (n-1). Получатели могут теперь проверить, что вы отправили все предыдущие сообщения, и никто не может подделать вашу подпись, так как прошел период времени, в течение которого она действительна.

Повторное хэширование сотен тысяч раз, как предполагает Билл, - пустая трата вашего процессора. Используйте более длинный ключ, если вы беспокоитесь о людях, ломающих 128 бит.

0 голосов
/ 08 декабря 2008

Я собираюсь выйти на конечность и сказать, что в определенных обстоятельствах она более безопасна ... но пока не понижайте меня!

С математической / криптографической точки зрения это менее безопасно, по причинам, которые, я уверен, кто-то другой даст вам более четкое объяснение, чем я мог бы.

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

Конечно, если вы используете соль, то это преимущество (недостаток?) Исчезнет.

...