Многие привычные требования к паролям создают неудобства для пользователей, но не останавливают современные атаки. Узнайте, какие меры защиты рекомендуют сегодня NIST, NCSC и Microsoft.
Политику паролей часто воспринимают как контрольный список: требовать заглавную букву, цифру, специальный символ и смену пароля каждые 60 или 90 дней. Эти правила легко заметить и проверить, но их заметность не означает эффективности. Злоумышленники используют предсказуемые решения пользователей, повторно используемые учетные данные, слабые механизмы восстановления доступа и плохо защищенные базы паролей.
Полезная политика должна снижать эти конкретные риски и при этом оставаться достаточно удобной, чтобы пользователи не пытались ее обойти.
Минимальная длина
Длина увеличивает число возможных комбинаций, но только если пароль не представляет собой распространенную фразу или предсказуемую последовательность. Актуальные рекомендации NIST требуют не менее 15 символов, если пароль — единственный фактор аутентификации, и допускают снижение минимума до восьми символов, если пароль используется в составе многофакторной аутентификации. Системы должны принимать пароли длиной как минимум до 64 символов, чтобы менеджеры паролей и парольные фразы работали корректно.
Длина — это базовое требование, а не доказательство надежности. Необходим список блокировки скомпрометированных паролей: даже длинный пароль остается небезопасным, если он уже известен злоумышленникам.
Плановая смена паролей
Принудительная смена по фиксированному графику обычно приводит к небольшим и предсказуемым изменениям. Она также создает дополнительную нагрузку для каждого пользователя, даже если нет свидетельств того, что все пароли были раскрыты. NIST, британский NCSC и Microsoft не рекомендуют устанавливать срок действия паролей для их плановой смены. Вместо этого пароль следует менять при наличии свидетельств или обоснованных подозрений о его компрометации, после обнаружения небезопасного хранения или если этого требует восстановление аккаунта.
Организациям по-прежнему нужны средства для быстрого выявления компрометации и сброса паролей. Отказ от периодической смены не означает, что можно продолжать использовать заведомо скомпрометированный пароль.
Требования к составу пароля
Обязательные требования использовать заглавные и строчные буквы, цифры и специальные символы подталкивают пользователей к шаблонным решениям, например к заглавной букве в начале и цифре или символу в конце. Инструменты для атак уже учитывают такие замены. Сервисы должны разрешать пробелы и широкий набор символов, избегать произвольных требований к составу пароля и проверять предлагаемый пароль целиком по спискам распространенных и скомпрометированных паролей.
Блокировка знаков пунктуации из-за того, что они могут использоваться в SQL-инъекциях или межсайтовом скриптинге, — тревожный признак. Код приложения должен использовать параметризованные запросы к базе данных и безопасную обработку выводимых данных. Ограничения на пароль пользователя не заменяют устранение уязвимостей, допускающих инъекции.
Повторное использование паролей и утечки учетных данных
Повторное использование паролей — один из наиболее серьезных рисков: утечка у одного поставщика услуг может открыть доступ к аккаунтам у другого. Политика должна требовать уникального пароля для сервиса, поддерживать менеджеры паролей и предусматривать проверку предлагаемых паролей по известным скомпрометированным значениям с помощью метода, сохраняющего конфиденциальность. Организациям также следует отслеживать характерные признаки массовой подстановки учетных данных и необычное поведение при входе в систему.
История паролей может предотвратить повторное использование точно такого же пароля в одном сервисе, но слишком длинная история может подталкивать к косметическим изменениям. Она не позволяет выявить повторное использование паролей у других, не связанных между собой поставщиков услуг и не должна считаться основным средством защиты.
Безопасное хранение паролей
Пароли должны передаваться сервису только по защищенному соединению TLS и никогда не должны записываться в журналы. На сервере каждый пароль необходимо обрабатывать с уникальной случайной солью и медленной функцией хеширования, предназначенной специально для паролей. OWASP обычно рекомендует Argon2id; scrypt, bcrypt или PBKDF2 могут подходить при соблюдении оговоренных ограничений. По мере совершенствования оборудования параметры вычислительной сложности необходимо периодически пересматривать.
Значение pepper, хранящееся вне базы паролей, может добавить еще один уровень защиты, но требует управления ключами и их ротации. Оно не заменяет соль или надежную функцию хеширования паролей. Быстрые хеш-функции общего назначения, такие как MD5 и обычные SHA-1/SHA-2, сами по себе не подходят для хранения паролей.
Что включает эффективная политика
Минимальную длину с учетом рисков и поддержку длинных паролей.
Блокировку распространенных, предсказуемых и заведомо скомпрометированных паролей.
Поддержку менеджеров паролей, вставки из буфера обмена и автозаполнения.
Медленное хеширование паролей с уникальной солью для каждого пароля и пересмотром параметров вычислительной сложности.
Многоуровневое ограничение частоты попыток и выявление атак с подбором паролей, распылением паролей и массовой подстановкой учетных данных.
Устойчивую к фишингу MFA или ключи доступа (passkeys), особенно для привилегированных аккаунтов и аккаунтов с доступом к конфиденциальным данным.
Безопасное восстановление доступа, замену средств аутентификации, отзыв сеансов и сброс паролей при компрометации.
