Современные подходы к обеспечению безопасности паролей

Введение

Пароли удобны, но уязвимы из-за предсказуемого выбора, повторного использования и небезопасного хранения. Утечка RockYou в 2009 году раскрыла около 32 млн паролей в открытом виде.

Актуальность связана с утечками, обновлением рекомендаций по хешированию и развитием passkeys.

Bonneau и соавторы сравнили схемы веб-аутентификации [1, с. 553–567], а Weir и соавторы – вероятностный подбор [2, с. 391–405]. Цель обзора – сопоставить эти исследования с современными требованиями NIST и OWASP.

Типичные угрозы

Основные угрозы требуют разных мер защиты:

• Полный перебор – проверка комбинаций; увеличение длины случайного пароля повышает стоимость поиска.
• Словарные атаки – проверка популярных паролей и типовых изменений; вероятностные модели повышают эффективность подбора [2, с. 391–405].
• Офлайн-подбор – после кражи хешей варианты проверяются без ограничений сервиса; скорость зависит от алгоритма.
• Credential stuffing – автоматическая проверка пар из утечек на других сайтах из-за повторного использования.
• Фишинг и вредоносное ПО – кража данных на поддельном сайте или кейлоггером; сложность пароля не предотвращает её.

Хранение паролей на стороне сервера

Сервис хранит не пароль, а результат специализированной односторонней функции. Уникальная случайная соль мешает использовать готовые таблицы и выявлять одинаковые пароли. Дополнительный «перец» хранится отдельно от базы.

MD5 и SHA-256 слишком быстры для хранения паролей. Поэтому важны стойкость функции и стоимость каждой проверки (табл. 1).

Таблица 1

Функции для хранения паролей

Сравнение показывает, что Argon2id наиболее гибок: настраиваются память, время и параллелизм. scrypt также затрудняет перебор за счёт памяти. bcrypt совместим со многими системами, но ограничивает длину учитываемого пароля; PBKDF2 широко стандартизирован, однако его вычисления менее затратны для специализированного оборудования. Выбор зависит от требований совместимости и доступных ресурсов; параметры необходимо проверять на реальном сервере. OWASP отдаёт приоритет Argon2id [7].

Современные рекомендации и оценка стойкости

Стойкость случайного пароля оценивают энтропией:

                                            H = L · log₂ N,                                                 (1)

Для случайного пароля H = L · log₂ N, где L – длина, N – размер алфавита. Восемь случайных символов ASCII из 94 вариантов дают около 52 бит; сопоставимый результат даёт случайная фраза Diceware из четырёх слов.

Таблица 2

Энтропия случайных паролей по формуле (1)

Формула применима к случайным паролям: человеческий выбор предсказуем. Поэтому важны длина и непредсказуемость; случайная фраза надёжнее короткой комбинации с формально разными символами.

NIST SP 800-63B-4 [8] рекомендует:

• для единственного фактора – не менее 15 символов;
• не навязывать обязательные типы символов;
• не требовать регулярной смены без признаков компрометации;
• проверять новые пароли по спискам распространённых и скомпрометированных;
• разрешать вставку из менеджеров и длину не менее 64 символов.

Оценщики, например zxcvbn, выявляют словарные слова, последовательности, даты и повторы. Поэтому «P@ssw0rd1» оценивается как слабый пароль, несмотря на формальное разнообразие символов [9, с. 157–173]. Такие инструменты дополняют, но не заменяют проверку по спискам утечек.

Альтернативы и дополнения к паролям

Менеджеры создают уникальные пароли и снижают риск credential stuffing; их надёжность зависит от защиты главного пароля и хранилища.

Многофакторная аутентификация (MFA) снижает риск захвата аккаунта при утечке пароля. SMS-коды уязвимы к перехвату и подмене SIM, тогда как аппаратные ключи лучше защищают от фишинга.

Passkeys на основе FIDO2/WebAuthn используют пару ключей [10]. Привязка к домену снижает риск фишинга, а отсутствие общего секрета на сервере ограничивает последствия утечки. Для внедрения необходимы поддержка платформ и надёжное восстановление доступа.

Методы дополняют друг друга: менеджер предотвращает повторное использование, MFA добавляет фактор, passkeys уменьшают риск фишинга и отказа от пароля. Их внедрение зависит от совместимости сервисов и устройств.

Практические рекомендации

Практические рекомендации:

Пользователям:

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

Разработчикам:

• хранить солёные хеши Argon2id (либо корректно настроенных scrypt, bcrypt или PBKDF2);
• проверять пароли по спискам утечек;
• ограничивать попытки и разрешать длинные пароли и вставку из менеджеров;
• не навязывать обязательный состав и регулярную смену;
• предлагать MFA и passkeys.

Заключение

Сравнение позволяет заключить:

1. перебор требует дорогого хеширования, повторное использование – уникальных паролей, а фишинг – устойчивых к нему методов входа;
2. Argon2id и scrypt затрудняют перебор, bcrypt и PBKDF2 сохраняют актуальность при корректной настройке;
3. длина, непредсказуемость и проверка по спискам утечек важнее формальных правил и регулярной смены паролей;
4. менеджеры паролей, MFA и passkeys обеспечивают уникальность, дополнительную защиту и устойчивость к фишингу.