Аудит хранения паролей: хеширование, соль и безопасная миграция

Что проверяет аудит хранения паролей (и почему это важно)

Правильное хранение паролей — это простая идея: если кто‑то похитит вашу базу пользователей, эти пароли всё равно нельзя будет использовать.

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

Аудит хранения паролей проверяет всю цепочку, а не только экран входа. В унаследованном коде (особенно сгенерированном быстро инструментами AI) входы могут «работать», но хранение быть небезопасным. В прототипе пароли могли хешироваться быстрым алгоритмом, использовать одну и ту же соль или случайно логировать секреты при отладке. Всё это не ломает счастливый путь, но превращает утечку данных в волну захватов аккаунтов.

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

Хорошее хранение паролей обычно включает:

• Современный медленный алгоритм хеширования паролей (не общий хеш вроде MD5 или SHA‑1).
• Уникальную случайную соль для каждого пароля, хранимую рядом с хешем.
• Опциональный pepper: отдельный секрет вне базы данных.
• Явное версионирование, чтобы можно было менять настройки без ломки входа.
• Отсутствие случайных утечек (логи, аналитика, сообщения об ошибках, бэкапы).

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

Обычный план — «rehash при следующем входе»: пользователи продолжают входить как обычно, а когда пароль успешно проверен, вы обновляете их хеш до нового стандарта.

Срочные тревожные сигналы, которые легко заметить в унаследованном коде

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

Самый тревожный сигнал — всё, что позволяет восстановить пароль. Если вы видите пароли, сохранённые прямо в колонке базы, залогированные в консоли, отправленные в аналитику или «зашифрованные» обратимо (например, AES с сохранённым ключом), рассматривайте это как инцидент. Пароли должны храниться только как односторонние хеши.

Ещё одна распространённая проблема — использование быстрых хешей. Может быть видно MD5, SHA‑1 или простой SHA‑256, применённый к паролю. Даже если он «выглядит как хеш», быстрые алгоритмы созданы для скорости и легко ломаются в масштабе. Если в коде написано hash(password) и ничего больше, это сильный признак неправильного использования функции хеширования паролей.

Быстрые проверки, которые ловят большинство серьёзных проблем:

• Упоминания md5, sha1, sha256(password) или вспомогательных методов вроде "encryptPassword".
• Хеши одинаковой длины и формата без признаков пер‑пользовательской соли.
• Пароли или токены для сброса, попадающие в логи, отчёты об ошибках или дампы базы.
• Секреты (ключи JWT, пароли БД, PEPPER=...) захардкожены в репозитории или конфиге.
• Код входа, предпологающий только один формат хеша и не имеющий пути обновления.

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

Практический пример: вы унаследовали Node‑приложение и видите колонку users.password, заполненную 64‑значными hex‑строками. Хендлер входа делает sha256(req.password) и сравнивает с базой. Это «работает», но уязвимо и не даёт безопасного пути к улучшению без учёта нескольких форматов хеша.

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

Картирование мест, где обрабатываются пароли и потоки сброса

Аудит идёт быстрее, если начать с простой карты: все места, где пароль или токен сброса создаётся, отправляется, обрабатывается или хранится. В унаследованном коде рисковые участки зачастую не в папке «auth»: они разбросаны по формам UI, API‑маршрутами, фоновых задачам и административным инструментам.

Начните с перечисления каждой точки входа, через которую пароль может попасть в систему, затем подтвердите каждую из них в коде и в продакшн‑конфигурациях. Частые места: регистрация, вход (включая обходные пути SSO), сброс и восстановление пароля, админ/поддержка и импорты или миграции (CSV‑загрузки, синхронизация CRM, seed‑скрипты).

Далее найдите, где в базе хранится связанная с паролем информация. Проверьте очевидные колонки (password, password_hash, hashed_password), а также старые таблицы и теневые копии (например, users_legacy, которые ещё может читать фоновая задача). Если есть несколько полей для хеша пароля, отметьте, какое именно используется при входе.

Логирование — ещё один распространённый источник утечек. Ищите в коде и в настройках мониторинга всё, что может захватить чувствительные значения: request logs, события аналитики, отчёты об ошибках и debug prints. Реалистичная ошибка: обработчик неудачного входа логирует полное тело запроса «для отладки», тихо отправляя открытые пароли в логи.

Потоки сброса пароля заслуживают собственной мини‑карты, потому что токены легко обрабатывать неправильно. Определите, как генерируются токены сброса (источник случайных чисел), где они хранятся (строка в базе, кэш, полезная нагрузка ссылки в письме) и как истекают. Также проверьте, одноразовые ли токены и что происходит при повторном использовании токена после смены пароля.

Наконец, обозначьте границы сервиса. Отметьте все компоненты, которые касаются аутентификации: клиент, API‑шлюз, сервис аутентификации, фоновые воркеры (email, SMS) и любые сторонние провайдеры идентификации. В AI‑сгенерированных проектах часто находят лишние эндпоинты, оставшиеся после итераций, поэтому включите старые маршруты и отключённые feature‑флаги в сканирование.

Подтвердите алгоритм хеширования и его настройки

Аудит хранения паролей начинается с прямого вопроса: вы используете функцию хеширования паролей или общий хеш?

Если вы видите MD5, SHA‑1, SHA‑256 или что‑то, описанное как «encrypt password», считайте это серьёзной проблемой. Эти инструменты не предназначены, чтобы замедлять атакующего.

Предпочитайте специализированные хеши паролей: Argon2id, bcrypt или scrypt. Они сделаны так, чтобы взлом стоил дорого, так что слитые хеши сложнее превратить в реальные пароли.

Как понять по хешу, что у вас применяется

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

Типичные паттерны:

• Argon2id часто начинается с $argon2id$ и содержит параметры памяти и итераций.
• bcrypt часто начинается с $2a$, $2b$ или $2y$ и содержит cost вроде 10 или 12.
• scrypt может содержать $scrypt$ или параметры N, r, p в зависимости от библиотеки.

Если вы видите фиксированную hex‑строку (например, 32 или 64 hex символа) без $‑разделителей, это может быть общий хеш или кастомная схема, требующая более глубокого обследования.

Проверяйте настройки, а не только имя

Выбор алгоритма — лишь половина истории. Argon2id может быть слабым при малом объёме памяти. bcrypt — слабым при низком cost.

Найдите, где задаётся фактор работы (work factor) и можно ли менять его без деплоя. Здоровые настройки держат параметры в конфиге, используют встроенный verify метода библиотеки (а не ручные сравнения строк) и сравнивают в константное время.

Также убедитесь, что у эндпоинта входа есть базовые защиты: rate limiting по аккаунту и по IP, а также разумные правила блокировок. Короткие временные блокировки обычно безопаснее постоянных.