Забавное: MD5 – с добрым утром!

В 2012 году на roem.ru сообщают: “MD5 больше не надёжен”.

Вообще, о том, что MD5 не является стойким вариантом для преобразования паролей с целью их сохранения, стало известно примерно через пару лет после разработки MD5 (1991). Но, спустя ещё, примерно, два десятка лет – “ненадёжность” MD5 остаётся открытием. В принципе, это объясняет и то, почему разработчики продолжают MD5 применять везде, где только могут.

()

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 12

  • 1. 8th June 2012, 14:28 // Читатель jno написал:

    Вот уже в зубах навязла эта “ненадёжность”…
    И, что характерно, чисто журналюжный подход: сенсация, типа!
    Без циферок, ту “надёжность/ненадёжность” характеризующих.
    Тем более, что и сам термин в данном контексте является некорректным.
    Раз уж спич идёт об МД5 как о средстве “шифрования”, то и говорить надо о стойкости.

    Самое же забавное, что *на*практике* по сей день нет особой разницы между традиционным 3DES, древним CRC32, “ненадёжным” MD5 и, скажем, SHA-1. Да ещё и без учёта природы “шифруемых” данных (длинные стойкие пароли или 4-циферные PINы, к примеру).

  • 2. 8th June 2012, 20:05 // Читатель Jeff Zanooda написал:

    Ну я вообще не помню, чтоб кто-то раньше использовал коллизию в MD5 в корыстных целях.

    Flame – первый случай, они вроде именно так подписали свой код микрософтовским сертификатом.

  • 3. 8th June 2012, 20:20 // Читатель Jeff Zanooda написал:

    > *на*практике* по сей день нет особой разницы между традиционным 3DES, древним CRC32, “ненадёжным” MD5 и, скажем, SHA-1

    Конечно, есть. Если бы LinkedIn хранил хеши паролей в CRC32, пользователям не осталось бы времени сменить свои пароли в других местах (если они использовали их повторно).

    Не все хеши должны быть криптографически стойкими, но как раз хеши паролей должны быть. Почему бы не использовать SHA-512.

  • 4. 9th June 2012, 13:31 // Читатель sarin написал:

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

    это я к паролям LinkedIn которые в CRC32.

  • 5. 10th June 2012, 12:08 // Александр Венедюхин ответил:

    Нет, гарантии такой, естественно, нет, так как это вообще разные вещи – CRC32 и современные хеш-функции. Речь же шла о том, что найти подходящие пароли под CRC32 несравнимо проще, чем в случае, если используется стойкая хеш-функция.

  • 6. 10th June 2012, 22:46 // Читатель sarin написал:

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

  • 7. 11th June 2012, 19:28 // Читатель Jeff Zanooda написал:

    Дело не только в том, что для CRC32 можно легко подобрать коллизию.

    Поскольку CRC32 не является односторонней функцией, по ней можно быстее (чем грубым перебором) восстановить исходный пароль, или по крайней мере очень сильно сократить пространство поиска.

    То есть не просто найти последовательность байт с тем же CRC32, а именно исходный пароль.

    Даже если ограничиться грубым перебором, CRC32 считается намного быстрее. Если пароли не подобрать за день-другой, то толку мало – пользователи увидят новости и пароли поменяют.

  • 8. 13th June 2012, 14:53 // Читатель sarin написал:

    как это CRC32 не является односторонней функцией?

    я не понимаю, как по всем этим хешам можно восстановить исходный пароль? вот CRC32 – 4 байта, если ничего не путаю. чуть более четырёх миллиардов. допустим Имярек использует пароль для записи которого нужно 6 байт. таких паролей будет в 65536 раз больше, чем может быть различных CRC32.

    допустим мы знаем CRC32 пароля и получаем все возможные пароли которые дадут такой же хеш. какой из них является исходным? если нам известна свёртка по другой функции – нет проблем! рассчитаем хеши по этой функции для всех найденных паролей и готово. но других вариантов я не вижу.

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

  • 9. 13th June 2012, 22:06 // Читатель Jeff Zanooda написал:

    Даже если у имярека пароль длиной 6 байт, это скорее всего 6 ASCII символов. 26 букв * 2 регистра + 10 цифр = 62 варианта. Пусть будет 64, чтоб с запасом, то есть 2^6. Итого 2^36, в среднем на один CRC32 получим 2^(36-32) = 16 вариантов, один из которых – правильный.

    Угадать, какой из 16 паролей – настоящий, уже должно быть несложно. Заглавные буквы обычно в начале, цифры – в конце, слова из словаря используются и т.д. Если подбираем пароль к какому-нибудь другому ресурсу и там ограничение на три попытки, вероятность угадать 1-(15/16)^3 = 18%, вполне приемлемо.

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

    Если бы скорость хеш-функции никого не волновала, никто бы не солил хеши.

  • 10. 14th June 2012, 00:35 // Читатель sarin написал:

    чтобы создать таблицу MD5 для 2**36 вариантов паролей необходимо примерно 2 Тб диска.
    мой ноут считает MD5 145 микросекунд. резонно предположить, что радужные таблицы для паролей в 6 символов давно уже есть у всех, кому нужны.

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

  • 11. 14th June 2012, 01:06 // Читатель Jeff Zanooda написал:

    А CRC32 считает небось за микросекунду, и сравнивает два готовых хеша тоже.

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

  • 12. 14th June 2012, 12:32 // Читатель sarin написал:

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

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