Многократное шифрование (MD5) может улучшить безопасность? - PullRequest
6 голосов
/ 29 июля 2011

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

Ответы [ 4 ]

4 голосов
/ 29 июля 2011

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

Что произойдет, если вы примените хеш несколько раз?Выход будет оставаться в том же диапазоне (2 ^ 128).Это как будто ты говоришь "Угадай мое случайное число!"двадцать раз, каждый раз думая о новом числе - это не делает его сложнее или легче угадать.Нет более «случайного», чем случайного.Это не идеальная аналогия, но я думаю, что это помогает проиллюстрировать проблему.

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

Так почему же до сих пор не все потеряно при таком подходе?Это из-за того, что другие высказались о тысячах итераций вместо всего лишь двадцати.Почему это хорошо, замедляя алгоритм?Это потому, что большинство злоумышленников будут пытаться получить доступ, используя словарь (или радужную таблицу , используя часто используемые пароли, надеясь, что один из ваших пользователей проявил небрежность, чтобы использовать один из них (я виноват, по крайней мере,Ubuntu сказал мне об установке). Но с другой стороны, негумано требовать от ваших пользователей запоминания, скажем, 30 случайных символов.

Вот почему нам нужна некоторая форма компромисса между легко запоминающимися паролями, но приВ то же время злоумышленникам будет трудно угадать их. Существуют две общие практики: соли и замедление процесса путем применения множества итераций некоторой функции вместо одной итерации. PKCS# 5 является хорошим примером для изучения.

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

Но почему использование соли все же лучше?Потому что даже если вы примените хеш-код 20000 раз, находчивый злоумышленник может предварительно вычислить большую базу паролей, хешируя каждый из них 20000 раз, эффективно создавая настраиваемую радужную таблицу, специально предназначенную для вашего приложения.Сделав это, они могут довольно легко атаковать ваше приложение или любое другое приложение по вашей схеме.Вот почему вам также необходимо сгенерировать высокую цену за пароль, чтобы сделать использование таких радужных таблиц нецелесообразным.

Если вы хотите быть действительно безопасным, используйте что-то вроде PBKDF2, показанное в PKCS # 5.

1 голос
/ 30 июля 2011

Есть такой вопрос на crypto.SE, но сейчас он НЕ общедоступен.Ответ Paŭlo Ebermann :

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

См. Подробнее о безопасном хранении пароля .

Важным моментом является то, что взломщикам паролей не нужно взламывать пространство вывода хеша (2 160 для SHA-1), но только место для пароля, которое намного меньше (в зависимости от ваших правил паролей - и часто помогают словари).Таким образом, нам нужна не быстрая хеш-функция, а медленная.Bcrypt и его друзья предназначены для этого.

И на аналогичный вопрос есть ответы: Вопрос «Защита от криптоаналитических прорывов: объединение нескольких хэш-функций» Ответ от Томас Порнин :

Объединение - это то, что SSL / TLS делает с MD5 и SHA-1, в своем определении их внутреннего "PRF" (который на самом деле является функцией получения ключа ).Для данной хеш-функции TLS определяет KDF, который опирается на HMAC, который опирается на хеш-функцию.Затем KDF вызывается дважды, один раз с MD5 и один раз с SHA-1, и результаты XORed вместе.Идея состояла в том, чтобы противостоять криптоаналитическим перерывам в MD5 или SHA-1.Обратите внимание, что XOR для вывода двух хеш-функций опирается на тонкие предположения.Например, если я определю SHB-256 ( m ) = SHA-256 ( m ) XOR C , для фиксированной постоянной C , тогда SHB-256 является такой же хорошей хэш-функцией, как и SHA-256;но XOR обоих всегда дает C , что совсем не хорошо для целей хеширования.Следовательно, конструкция в TLS на самом деле не санкционирована авторитетом науки (просто так получилось, что она не была нарушена). TLS-1.2 больше не использует эту комбинацию;он опирается на KDF с единственной настраиваемой хэш-функцией, часто SHA-256 (что в 2011 году было разумным выбором).

Как указывает @PulpSpy, объединение не является хорошим общим способом построенияхэш-функции.Это было опубликовано Жу в 2004 году, а затем обобщено Хохом и Шамиром в 2006 для большого класса конструкций, включающих итерации и конкатенации.Но обратите внимание на мелкий шрифт: на самом деле речь идет не о выживающих слабостях хэш-функций, а о том, как заработать свои деньги.А именно, если вы возьмете хеш-функцию с 128-битным выходом и другую с 160-битным выходом и объедините результаты, то сопротивление столкновению будет не хуже, чем у самой сильной из двух;Жу показал, что она тоже не будет намного лучше.Имея 128 + 160 = 288 битов на выходе, вы можете стремиться к сопротивлению 2 144 , но результат Жу подразумевает, что вы не выйдете за пределы 2 87 .

Таким образом, возникает вопрос: существует ли способ, если это возможно, эффективный способ , чтобы объединить две хеш-функции так, чтобы результат был таким же устойчивым к столкновениям, как и самая сильная из двух, но без увеличения выходного сигналаконкатенация?В 2006 году Бонех и Бойен опубликовали результат, в котором просто говорится, что ответ отрицательный, при условии, что каждая хеш-функция оценивается только один раз. Редактировать: Pietrzak снял последнее условие в 2007 году (то есть несколько раз не вызывать каждую хэш-функцию не помогает).

И PulpSpy :

Уверен, @ Томас даст исчерпывающий ответ.Тем временем, я просто укажу, что сопротивление столкновению вашей первой конструкции, H1 (m) || H2 (M), на удивление не намного лучше, чем просто H1 (M).См. Раздел 4 этого документа:

http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf

1 голос
/ 29 июля 2011

Хеширование пароля не является шифрованием.Это односторонний процесс.

Проверьте security.stackexchange.com и вопросы, связанные с паролем.Они настолько популярны, что мы собрали это сообщение в блоге специально, чтобы помочь людям найти полезные вопросы и ответы.

Этот вопрос специально обсуждается с использованием md520 раз подряд - посмотрите ответ Томаса Порнина.Ключевые моменты в своем ответе:

  • 20 слишком мало, должно быть 20000 или более - обработка пароля все еще слишком быстрая
  • Соли нет: злоумышленник может атаковать пароли с помощьюочень низкая стоимость за пароль, например, радужные таблицы, которые могут быть созданы для любого количества циклов md5
  • Поскольку нет точного теста для определения того, является ли данный алгоритм безопасным или нет, изобретать собственную криптографию часторецепт катастрофы.Не делай этого
0 голосов
/ 29 июля 2011

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

...