Тестировщику предоставили дамп таблицы пользователей с паролями. По каким признакам определить, что хранение допускает эффективный офлайн-подбор?
Хранение допускает эффективный офлайн-подбор, если пароль представлен обратимо либо защищён быстрым или устаревшим хешированием без уникальной соли и достаточной вычислительной стоимости. Тестировщик должен определить алгоритм, наличие индивидуальной соли, параметры трудоёмкости и проверить устойчивость нескольких контролируемых паролей к автономному подбору.
Ранние системы иногда хранили пароли в открытом виде или шифровали их обратимым способом. Компрометация базы в таком случае сразу раскрывала учётные данные либо ключ для их восстановления.
Криптографическое хеширование решило проблему обратимого восстановления, но обычные быстрые хеши оказались слишком удобны для перебора. Поэтому появились функции хранения паролей с уникальной солью и регулируемой вычислительной стоимостью: bcrypt, scrypt, Argon2id и PBKDF2.
При утечке базы злоумышленник получает возможность проверять предполагаемые пароли локально, не взаимодействуя с приложением. Ограничение числа попыток входа, CAPTCHA и блокировка учётной записи в этом сценарии уже не защищают базу.
Опасными признаками являются открытые пароли, обратимое шифрование, одинаковая соль для всех пользователей, отсутствие соли, быстрые хеши общего назначения и слишком низкие параметры вычислительной стоимости. Даже современный алгоритм не гарантирует безопасность слабых или повторно используемых паролей.
Сначала нужно классифицировать формат значения: определить, содержит ли оно название алгоритма, версию, соль и параметры стоимости. Если формат непрозрачен, следует изучить реализацию формирования и проверки паролей, а не делать вывод только по длине строки.
Соль должна быть уникальной для каждого пароля и храниться вместе с хешем. Она не обязана быть секретной: её задача — сделать заранее подготовленные таблицы и массовое сравнение одинаковых паролей неэффективными.
Алгоритм должен быть предназначен именно для хранения паролей и иметь настраиваемую стоимость. Argon2id дополнительно расходует память, что усложняет массовый перебор на специализированном оборудовании; bcrypt, scrypt и PBKDF2 также могут быть корректными при актуальных параметрах. Нельзя объявлять систему безопасной только по названию алгоритма без проверки версии и настроек.
Практическая проверка проводится на тестовых учётных данных: подбирается пароль с известной сложностью, оценивается время одной проверки и подтверждается, что одинаковые пароли разных пользователей имеют разные значения хранения. Проверка должна выполняться в изолированной среде и на разрешённых данных, поскольку массовый перебор реальных паролей создаёт риск их раскрытия.
Важно различать проверку стойкости хранения и проверку политики паролей. Длинный пароль помогает против перебора, но не компенсирует открытое хранение или быстрый хеш. При повышении стоимости хеширования нужно учитывать нагрузку на вход в систему и риск отказа в обслуживании; обычно параметры выбирают по измерениям на рабочей инфраструктуре и постепенно обновляют при успешной аутентификации.
В дампе обнаружены значения одинакового формата, а пользователи с одинаковыми тестовыми паролями имеют одинаковые хеши. Рассматривались три варианта: считать наличие хеша достаточной защитой, попытаться подобрать пароли на рабочей базе или исследовать механизм на копии с контролируемыми данными.
Первый вариант опасен, потому что не выявляет отсутствие соли и использование быстрого алгоритма. Второй нарушает принцип минимизации риска и может раскрыть реальные пароли. Выбран третий вариант: на стенде создают несколько тестовых учётных записей, сравнивают формат и параметры хранения, затем измеряют скорость автономной проверки известных тестовых паролей.
Проверка показала использование быстрого хеша без индивидуальной соли. Результат зафиксировали как уязвимость утечки учётных данных с рекомендацией перейти на адаптивное хеширование, добавить уникальную соль для каждого пароля и выполнять постепенное обновление хешей после успешного входа.
Нет. Соль предотвращает эффективное использование заранее подготовленных таблиц и скрывает совпадение одинаковых паролей, но не замедляет каждую отдельную попытку. Сочетание уникальной соли с быстрым хешем всё ещё оставляет базу уязвимой для быстрого автономного перебора.
Нет. Шифрование обратимо: тот, кто получит ключ или доступ к операции расшифрования, сможет восстановить все пароли. Для проверки введённого пароля обычно используют одностороннюю функцию хранения с солью; обратимое шифрование допустимо для некоторых секретов, которые приложение должно восстановить, но пароль к ним обычно не относится.
Нельзя просто заменить значения без знания исходных паролей. Практичный переходный вариант — при успешном входе проверить старый формат, затем пересохранить пароль с новым алгоритмом и параметрами; для неактивных учётных записей применяют принудительную смену пароля или сброс с безопасным токеном. Одновременно нужно контролировать срок миграции, ограничить риск перебора и не сохранять старый пароль после успешного обновления.