Реакция на компрометацию базы данных с хешами

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

Ключевые свойства bcrypt:

  • наличие соли (salt) в каждом хеше
  • настраиваемая стоимость вычислений (cost factor)
  • устойчивость к радужным таблицам
  • значительное замедление brute-force атак

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

Что реально получает атакующий

При утечке базы с bcrypt-хешами:

  • отсутствует необходимость взаимодействия с сервером аутентификации
  • возможен полный перебор паролей с использованием GPU/ASIC
  • атака становится параллелизуемой
  • скорость атаки ограничивается только параметрами cost и вычислительными ресурсами

Даже при bcrypt с высоким cost, слабые пароли (короткие, словарные, повторяющиеся) становятся уязвимыми в разумные сроки.

Особенности bcrypt.js в контексте безопасности

Библиотека bcrypt.js реализует bcrypt на JavaScript и используется как в Node.js, так и в браузерных окружениях. Основные операции:

  • генерация хеша: bcrypt.hash
  • проверка пароля: bcrypt.compare
  • оценка cost-фактора через структуру хеша

Пример проверки пароля:

import bcrypt from "bcryptjs";

const password = "user_password";
const hash = await bcrypt.hash(password, 12);

const isValid = await bcrypt.compare(password, hash);

Внутри хеша уже содержится salt и cost factor, например:

$2a$12$......................

Немедленные действия после обнаружения утечки

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

Инвалидация сессий

Первый критический шаг — принудительный выход всех пользователей:

  • удаление session tokens
  • инвалидирование JWT через версионность токена или blacklist
  • сброс refresh-токенов

Это ограничивает использование уже полученных сессий даже при последующем восстановлении пароля.

Принудительный сброс паролей

Если утечка подтверждена:

  • все пароли считаются потенциально раскрытыми
  • инициируется forced password reset
  • старые хеши больше не считаются доверенными

Важно учитывать: bcrypt не позволяет «защитить» уже утекший хеш, так как он предназначен только для проверки, а не для восстановления.

Повышение стоимости bcrypt после инцидента

Если утечка произошла при недостаточном cost factor (например, 8–10), необходимо увеличить параметр сложности.

const NEW_COST = 14;

const newHash = await bcrypt.hash(password, NEW_COST);

Увеличение cost:

  • линейно увеличивает время вычисления
  • экспоненциально увеличивает стоимость brute-force
  • снижает эффективность GPU-атак

Однако увеличение cost не защищает уже утекшие хеши — только будущие.

Проверка устаревших хешей (rehash strategy)

Практическая защита включает проверку актуальности параметров хеша при логине.

bcrypt.js позволяет определить необходимость повторного хеширования:

function needsRehash(hash, currentCost = 14) {
  const parts = hash.split("$");
  const cost = parseInt(parts[2], 10);
  return cost < currentCost;
}

Использование:

const isValid = await bcrypt.compare(password, hash);

if (isValid && needsRehash(hash)) {
  const newHash = await bcrypt.hash(password, 14);
  // сохранить новый хеш в базе
}

Таким образом происходит постепенная миграция пользователей на более стойкие параметры без принудительного сброса.

Добавление server-side pepper

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

const pepper = process.env.PEPPER_SECRET;

const hash = await bcrypt.hash(password + pepper, 12);

При утечке базы атакующий не сможет провести полноценный оффлайн brute-force без знания pepper.

Мониторинг и анализ последствий утечки

После инцидента необходимо учитывать, что часть атак может происходить уже оффлайн, но последствия проявляются в онлайн-среде:

  • рост успешных логинов с валидными паролями
  • попытки credential stuffing на других сервисах
  • аномальная активность аккаунтов
  • повторное использование скомпрометированных паролей

Для борьбы с этим применяются:

  • rate limiting на вход
  • IP reputation filtering
  • device fingerprinting
  • MFA как обязательный слой защиты

Повторное использование паролей и каскадная компрометация

Основная опасность утечки bcrypt-хешей заключается не в расшифровке всех паролей, а в статистическом восстановлении части из них.

После этого атакующий:

  • проверяет совпадения на других сервисах
  • использует словарные и гибридные атаки
  • эксплуатирует повторное использование паролей

Даже 1–5% восстановленных паролей достаточно для цепной компрометации внешних систем пользователей.

Устойчивость bcrypt в современных условиях

bcrypt остаётся устойчивым при корректных параметрах:

  • cost ≥ 12–14 для современных серверов
  • уникальная соль для каждого хеша
  • отсутствие слабых паролей у пользователей
  • наличие pepper на уровне приложения

Однако криптостойкость bcrypt не компенсирует организационные риски:

  • утечка базы превращает защиту в оффлайн-задачу атакующего
  • безопасность смещается от алгоритма к инфраструктуре и политике паролей
Оглавление