Коротко — почему текущая схема плоха и какие атаки возможны, затем план безопасной системы.
1) Уязвимости в схеме
- Используется простая быстрая функция $\text{MD5}$: она рассчитана на скорость, поэтому перебор паролей и словарные атаки очень быстры.
- Отсутствует соль: одинаковые пароли дают одинаковый хеш, что упрощает атаку по совпадениям и использование радужных таблиц.
- $\text{MD5}$ криптографически «сломана»: практичны атаки на коллизии (chosen‑prefix), ослаблена уверенность в стойкости.
- Нет разделения параметров/версий/pepper, нет защиты от оффлайн атак после утечки хешей.
2) Возможные атаки (кратко, с объяснениями)
- Offline brute force: при утечке базы атакующий проверяет кандидаты паролей локально, скорость зависит от GPU/ASIC — современные ускорители дают примерно $\sim 10^8$–$\sim 10^{10}$ хешей/с для быстрых функций типа $\text{MD5}$.
- Rainbow tables: без соли предвычисленные таблицы позволяют мгновенно переводить хеш в пароль для распространённых паролей.
- Коллизии: $\text{MD5}$ имеет практические коллизии и chosen‑prefix коллизии; это позволяет создавать разные входы с одним хешем. В контексте аутентификации это не напрямую даёт обратную функцию, но может быть использовано в сценариях, где атакующий контролирует часть входных данных или могут быть подменены хеши/файлы.
- Length‑extension/структурные векторы: $\text{MD5}$ — Merkle–Damgård, уязвима для некоторых протокольных атак (если хеш используется неправильно).
- Credential stuffing / повторное использование: одинаковые хеши и утечки с других сервисов облегчают автоматический подбор.
- Offline словарные атаки с радужными таблицами и ускоренным перебором: прямое следствие быстроты $\text{MD5}$ и отсутствия соли.
3) Полный план безопасной системы аутентификации (практические рекомендации)
- Хранение паролей:
- Никогда не храните простой хеш вида $\text{MD5}(password)$.
- Используйте адаптивные ресурсоёмкие KDF: рекомендовано $\text{Argon2id}$ (современный стандарт). Альтернативы: $\text{bcrypt}$, $\text{PBKDF2}$ (с достаточными итерациями).
- Пример начальных параметров (подберите тестированием под вашу инфраструктуру): $\text{Argon2id}(\text{time}=3,\text{memory}=64\text{MiB},\text{parallelism}=4)$. Для $\text{PBKDF2}$ — итерации $\ge 10^5$; для $\text{bcrypt}$ — cost $\ge 12$. Подбирайте так, чтобы один хеш занимал целевое время ~$\sim 100$–$\sim 500$ мс на сервере.
- Используйте уникальную крипто‑соль для каждого пользователя, длина соли $\ge 16$ байт: храните соль вместе с хешем. (записывать параметр алгоритма/версию вместе с записью).
- Рассмотрите серверный «pepper» — секретный ключ, хранимый отдельно (KMS/HSM), добавляемый к паролю перед хешированием; если KMS скомпрометирован — всё ещё риск, но при утечке БД без pepper оффлайн атаки сложнее. Рекомендуемая длина pepper $\ge 32$ байта.
- Храните метаданные: алгоритм, параметры, соль, версия — чтобы можно было обновлять параметры позже.
- Миграция устаревших хешей:
- При логине, если запись помечена старой схемой ($\text{MD5}$ или слабый KDF), после успешной аутентификации пересчитайте хеш с новой схемой и сохраните.
- Поддерживайте механизм массового принудительного сброса и принудительной смены пароля при критическом обновлении.
- Защита аутентификации и входа:
- TLS everywhere (HSTS, современные шифры).
- Сравнение хешей — в константное время.
- Ограничение попыток: комбинировать per‑account и per‑IP rate‑limits, экспоненциальная задержка, временная блокировка; CAPTCHA/2FA после порога.
- Логи и мониторинг: фиксировать необычные попытки, блокировать и оповещать админов. Дефенсивная аналитика для credential stuffing.
- Ввод 2FA: TOTP (Authenticator), U2F/WebAuthn для сильной 2‑факторной аутентификации; SMS — только как fallback.
- Проверка пароля на утечки: интегрировать сервисы типа Have I Been Pwned с k‑anonymity для отказа использования скомпрометированных паролей.
- База, бэкапы и инфраструктура:
- Шифрование БД/бэкапов на уровне диска и/или приложений; управлять ключами через KMS/HSM.
- Минимизация прав доступа к таблице паролей, аудит доступа.
- Регулярные тесты и пентесты, обновления зависимостей безопасности.
- Реакция на утечку:
- Иметь план: зафиксировать инцидент, сменить pepper (если есть), уведомить пользователей, требовать смену пароля, принудительно слить сессии, вращать ключи.
- Анализ: какие параметры утекли, какая информация доступна (соли/хеши/pepper).
4) Дополнительные мелкие, но важные моменты
- Не используйте свои собственные крипто‑реализации — берите проверенные библиотеки ($libsodium$, $argon2$ libs, bcrypt implementations).
- Не храните пароли в логах, в памяти держите минимальное время, очищайте буферы.
- Документируйте версионирование схемы хеширования в БД, чтобы безопасно мигрировать.
Коротко: замените $\text{MD5}(password)$ на адаптивный KDF (Argon2id) с уникальной солью ($\ge 16$ байт), при необходимости добавьте pepper, включите 2FA, лимиты попыток, мониторинг и план реагирования на утечки.