MD5 сломали в 2004 году. Почему им всё ещё пользуются?

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

Что именно ломается у хэш-функции

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

Устойчивость к коллизиям означает, что злоумышленник не должен уметь подобрать два разных сообщения с одинаковым хэшем. Именно это свойство потеряли MD5 и SHA-1. Устойчивость к нахождению прообраза отвечает на другой вопрос: можно ли по заданному хэшу найти сообщение, которое его породило. Наконец, подбор пароля обычно атакует не абстрактную хэш-функцию, а конкретную базу быстро вычисляемых, плохо защищённых хэшей. Коллизии не раскрывают пароль автоматически, но высокая скорость MD5 и SHA-1 всё равно делает их неподходящими для хранения паролей.

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

MD5: от осторожной замены MD4 до поддельного центра сертификации

Рональд Райвест разработал MD5 в 1991 году как более осторожное развитие MD4. Опубликованный в апреле 1992 года RFC 1321 прямо объяснял, что MD4 начали применять быстрее, чем успели всесторонне исследовать, поэтому новый алгоритм пожертвовал частью скорости ради большего запаса безопасности. В то время MD5 считался разумным выбором для компактного 128-битного отпечатка и быстро распространился в программах, протоколах и инфраструктуре открытых ключей.

Первые серьёзные предупреждения появились задолго до окончательного практического взлома, но переломным стал 2004 год, когда Ван Сяоюнь, Дэнгуо Фэн, Сюэцзя Лай и Хунбо Ю опубликовали первые пары сообщений с одинаковым MD5. Подробная техника вышла в 2005 году, после чего исследователи начали не просто ускорять поиск коллизий, а учиться придавать сталкивающимся сообщениям полезную структуру. Краткую хронологию этих работ фиксирует RFC 6151, который позднее признал MD5 неприемлемым для задач, требующих устойчивости к коллизиям.

Особенно важным оказался метод выбранного префикса. Он позволял начать с двух заранее подготовленных документов, добавить к каждому вычисленные блоки и получить одинаковый MD5. В 2008 году команда Марка Стивенса применила эту технику против коммерческого центра сертификации и создала поддельный сертификат промежуточного CA. Браузер доверял корневому центру, а значит, доверял и выпущенным через поддельный промежуточный сертификат сайтам. После этой демонстрации коллизия перестала быть лабораторной особенностью и стала прямой угрозой модели доверия веба.

Почему MD5 всё ещё встречается

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

Есть и более узкий сценарий: обнаружение случайного повреждения данных в среде, где злоумышленник не управляет входом. Для такой задачи не требуется криптографическая устойчивость к коллизиям, поэтому старые системы продолжают использовать MD5 как привычную и повсеместно доступную контрольную сумму. Однако граница здесь принципиальна. Как только недоверенная сторона может специально подготовить файл, MD5 нельзя использовать для подписи, проверки подлинности, content-addressed storage или решения, в котором одинаковый хэш означает одинаковое содержимое.

Для паролей ситуация другая. Даже если забыть о коллизиях, MD5 и SHA-1 вычисляются слишком быстро, поэтому атакующий может проверять огромное количество кандидатов в секунду. Пароли нужно хранить с помощью специально медленных функций выработки ключа, например Argon2id, scrypt, bcrypt или PBKDF2, с уникальной солью и подходящими параметрами стоимости.

SHA-1: предупреждение появилось раньше практической коллизии

NIST стандартизировал SHA-1 в 1995 году как исправленную замену SHA-0. Десять лет спустя новые криптоаналитические результаты заметно сократили ожидаемую сложность поиска коллизии, и в 2006 году NIST уже призывал быстро переходить на SHA-2 в цифровых подписях. На тот момент полной публичной коллизии SHA-1 ещё не существовало, но прежнего запаса безопасности тоже не осталось.

Практическая точка была поставлена в 2017 году, когда Google и CWI Amsterdam представили SHAttered, первую публичную коллизию полного SHA-1. Исследователи создали два разных PDF-файла с одинаковым хэшем, выполнив около девяти квинтиллионов вычислений SHA-1. Работа потребовала ресурсов, эквивалентных примерно 6500 годам одного CPU для первой фазы и 110 годам одного GPU для второй. Атака оставалась дорогой, но уже находилась в пределах возможностей крупной организации и окончательно лишила SHA-1 права считаться надёжной основой цифровых подписей.

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

SHA-2 и SHA-3 не являются двумя поколениями одной замены

Семейство SHA-2 появилось в стандарте NIST в 2002 году и включает SHA-224, SHA-256, SHA-384 и SHA-512. Для новых систем самым распространённым универсальным выбором остаётся SHA-256: известных практических атак на его полную версию нет, он широко поддерживается и подходит для цифровых подписей, отпечатков файлов и других задач, где требуется современная криптографическая хэш-функция.

После атак на MD5 и SHA-1 NIST провёл открытый конкурс нового алгоритма с конструкцией, не повторяющей SHA-2. Победителем в 2012 году стал Keccak, разработанный Гвидо Бертони, Йоаном Даменом, Михаэлем Петерсом и Жилем Ван Аше; в 2015 году он был опубликован как SHA-3 в FIPS 202. При этом NIST отдельно подчёркивает, что SHA-2 остаётся безопасным и пригодным для использования. Более высокий номер не делает SHA-3 обязательной заменой SHA-256, а даёт индустрии альтернативу с другой внутренней математикой.

Разница конструкций проявляется и в способах использования. Наивный код SHA256(secret || message) уязвим для атаки удлинением сообщения, потому что SHA-256 позволяет продолжить вычисление из опубликованного внутреннего состояния. У SHA-3 с губчатой конструкцией этой конкретной проблемы нет, но правильным решением для аутентификации сообщения всё равно служит стандартная ключевая конструкция, а не самодельная склейка секрета и данных.

HMAC: зачем хэшу нужен ключ

Обычный хэш может вычислить любой человек, поэтому совпадение с заранее полученным доверенным значением помогает проверить целостность данных, но ничего не говорит об их отправителе. HMAC добавляет секретный ключ и создаёт код аутентификации сообщения: проверить его может сторона, которая знает тот же ключ. Конструкция была стандартизирована в RFC 2104 в 1997 году Михиром Белларе, Раном Канетти и Хьюго Кравчиком.

HMAC использует два вложенных вычисления, а не простую формулу hash(key + message):

HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) )

Здесь K' обозначает ключ, приведённый к размеру блока, ipad и opad являются фиксированными заполнителями, а || означает конкатенацию. Внутреннее вычисление связывает сообщение с ключом, после чего внешний слой скрывает промежуточное состояние и не позволяет продолжить его обычной атакой удлинения. Для новых систем обычно выбирают HMAC-SHA-256 или HMAC-SHA-512.

Какой алгоритм выбирать сегодня

Что умеет наш хэш-генератор

Hash Generator вычисляет хэши прямо в браузере и не отправляет введённый текст или выбранный файл на сервер. MD5 и SHA-1 оставлены для проверки старых данных и совместимости, а для новых задач доступны современные варианты:

• SHA-256, SHA-384 и SHA-512 из семейства SHA-2;
• SHA3-256 и SHA3-512 с губчатой конструкцией Keccak;
• HMAC для аутентификации сообщения секретным ключом;
• CRC32 для некриптографической проверки случайных ошибок;
• хэширование файлов и сравнение результата с известным значением;
• MD5 и SHA-1 для легаси-сценариев, где их требует существующий формат.

Чтобы увидеть различия, введите «Привет, мир», сравните 32 шестнадцатеричных символа MD5 с 64 символами SHA-256, а затем включите HMAC и добавьте ключ. Последний результат нельзя воспроизвести, зная только сообщение, поскольку для вычисления теперь требуется тот же секретный ключ.

Похожие инструменты

Генератор хешейСчитайте MD5, SHA-1, SHA-256/384/512, SHA-3 и CRC32 из текста или файлов вживую по мере ввода, с HMAC и сравнением хешей.JWT InspectorДекодируйте JWT в читаемый header и payload, проверяйте срок действия и время выпуска и проверяйте подписи HS256, RS256 или ES256 локально.Генератор UUIDГенерируйте UUID v4, v7 и v1, ULID, NanoID и CUID2-compatible идентификаторы с криптографически стойкой случайностью.Криптографический наборОпределяйте неизвестный шифр по алфавиту, индексу совпадений, частотам букв и повторам Касиски; кодируйте сообщение сразу всеми обратимыми шифрами с проверкой обратного преобразования; шифруйте через AES-256-GCM и решайте Цезаря, Виженера, Плейфера, ADFGX, Бифид или «забор» в верстаке — всё в браузере.Webhook Signature VerifierПроверка подписей webhook для семи провайдеров: точная подписываемая строка, окно защиты от replay и экспорт кода верификации для Node, Python, PHP и Go.Telegram Webhook TesterРазбор webhook-апдейтов Telegram Bot API, повторная отправка на любой endpoint и проверка или подпись initData Mini App через HMAC-SHA256 — полностью в браузере.