Устаревшие подходы

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Инженеру

Устаревшие подходы

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

Устаревшие криптографические хэш-функции

MD5

Алгоритм MD5, разработанный в 1992 году, был изначально ориентирован на контроль целостности, а не на безопасное хранение паролей. Однако долгое время он применялся для хэширования учётных данных.
Проблемы:

Коллизии могут быть найдены за считанные секунды на обычном оборудовании.
Полностью скомпрометирован: существуют готовые rainbow tables и сервисы обратного поиска.
Не обладает устойчивостью к атакам по времени и предвычислению.

Статус: запрещён для любых задач, связанных с безопасностью (RFC 6151).

SHA-1

Хотя SHA-1 значительно надёжнее MD5, к 2020-м годам были продемонстрированы практические атаки нахождения коллизий (проект SHAttered, 2017).
Проблемы:

Сниженная стойкость к коллизиям делает его непригодным для цифровых подписей и сертификатов.
Уже не поддерживается ведущими браузерами и ОС как стандарт для TLS.

Статус: устарел, не рекомендуется даже для целостности; заменён на SHA-2 (SHA-256, SHA-384) и SHA-3.

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

Небезопасные алгоритмы симметричного шифрования

DES (Data Encryption Standard)

Разработан в 1970-х, использует 56-битный ключ.
Проблемы:

Ключ слишком короткий: перебор возможен за часы на коммерческом оборудовании.
Уязвим к атакам на основе дифференциального и линейного криптоанализа.

Статус: объявлен небезопасным NIST в 1999 году.

3DES (Triple DES)

Являлся временной заменой DES: применяет DES трижды с разными ключами.
Проблемы:

Эффективная длина ключа ниже заявленной из-за слабостей конструкции.
Медленный и неэффективный по сравнению с современными алгоритмами.
Уязвим к атаке "встреча посередине" (meet-in-the-middle).

Статус: запрещён для новых применений (NIST SP 800-131A, 2023); поддержка прекращена в TLS 1.3.

ECB (Electronic Codebook) — режим шифрования

Часто ошибочно называют "EC4" (нет такого стандарта; вероятно, имеется в виду ECB).
Проблемы:

Одинаковые блоки открытого текста шифруются в одинаковые блоки шифротекста.
Нет диффузии: структура данных сохраняется (например, изображения остаются различимыми).
Не обеспечивает семантическую безопасность.

Статус: непригоден для шифрования данных с повторяющимися структурами. Допустим только для очень специфичных случаев (например, шифрование ключей по стандарту ANSI X9.52), но даже там предпочтительны другие режимы.

Современная альтернатива: AES (Advanced Encryption Standard) в режимах GCM (аутентифицированное шифрование) или CBC с корректной инициализацией (IV).

Хранение паролей без соли (salt)

Хэширование паролей без соли — фатальная ошибка.
Проблемы:

Позволяет применять rainbow tables — предвычисленные таблицы хэшей для миллионов распространённых паролей.
Одинаковые пароли разных пользователей дают одинаковые хэши, что упрощает массовую компрометацию.
Не защищает от атак по словарю даже при использовании "сильного" алгоритма (например, SHA-256 без соли всё ещё уязвим).

Требование — каждый пароль должен хэшироваться с уникальной, криптографически случайной солью, длиной не менее 16 байт. Соль хранится в открытом виде рядом с хэшем.

Хранение секретов в открытом виде

Plain text (открытый текст)

Хранение паролей, ключей API, токенов или других секретов в виде простого текста — недопустимо.
Примеры уязвимостей:

Пароли в исходном коде (hardcoded credentials);
Логирование паролей или токенов;
Конфигурационные файлы без шифрования;
Передача учётных данных в GET-параметрах URL.

Последствия — немедленный компромет при утечке логов, репозиториев, дампов памяти.

Решение — использовать сейфы секретов (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), переменные окружения (с осторожностью), или зашифрованные конфиги с контролем доступа.

Самопальные криптографические схемы

Разработка "собственного" алгоритма хэширования, шифрования или генерации ключей — один из самых опасных анти-паттернов.
Причины:

Криптография — область с чрезвычайно высоким порогом экспертизы.
Даже незначительная ошибка в конструкции делает систему полностью уязвимой.
Отсутствие peer review и долгосрочного анализа.

Принцип: никогда не изобретайте криптографию. Используйте только стандартизированные, широко проверенные алгоритмы и библиотеки (OpenSSL, libsodium, .NET Cryptography, Bouncy Castle).

Использование устаревших протоколов и механизмов

HTTP Basic Auth без TLS — передача логина/пароля в Base64 (не шифрование!);
Digest Access Authentication — устаревший, уязвимый к атакам на перехват сессии;
TLS 1.0 / 1.1 — содержат критические уязвимости (POODLE, BEAST); запрещены PCI DSS с 2018 года;
SSLv3 и ниже — полностью скомпрометированы.

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

Как безопасно мигрировать с устаревших решений

Раздел выше перечисляет "что нельзя". На практике команде нужен план "как перейти на современный стек без остановки сервиса".

Пошаговый план миграции

Инвентаризация
- найти в коде и инфраструктуре MD5, SHA-1, DES, 3DES, ECB, Basic Auth без TLS;
- зафиксировать, где эти механизмы используются и какие системы от них зависят.
Оценка рисков и приоритизация
- сначала выносить компоненты, которые доступны из интернета и обрабатывают персональные данные;
- отдельно отмечать участки, где уже были инциденты.
Параллельное включение новых механизмов
- для паролей: хранить новый формат хэшей при первом успешном входе пользователя;
- для транспорта: включать TLS 1.2+ и отключать старые протоколы поэтапно.
Контрольный период
- мониторить ошибки аутентификации, время отклика, количество отказов TLS-рукопожатий;
- иметь план быстрого отката конфигурации.
Закрытие легаси
- после контрольного периода удалить старые алгоритмы и ключи;
- обновить внутренние стандарты разработки и чек-листы ревью.

Мини-кейс

Команда перевела API с TLS 1.0 на TLS 1.2+, а затем отключила Basic Auth в пользу токенов. Результат:

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

Что проверить перед релизом

Все секреты вынесены из репозитория и CI-логов.
Для паролей используется Argon2id или bcrypt с индивидуальной солью.
Для симметричного шифрования используется AES-GCM.
На внешних интерфейсах запрещены SSLv3, TLS 1.0 и TLS 1.1.
Есть автоматическая проверка криптографических настроек в CI/CD.

Устаревшие подходы