Фундаментальная проблема аутентификации по паролю

При традиционной аутентификации по паролю клиент отправляет серверу пароль или его хеш, а сервер сравнивает полученное значение с сохранённым. Эта модель проста, но сосредотачивает огромный риск на сервере: компрометация базы данных одновременно раскрывает учётные данные всех пользователей.

Если злоумышленник взламывает сервер и крадёт базу паролей, он может проводить автономную словарную атаку с полной скоростью GPU без ограничений частоты запросов. Современные GPU способны проверять миллиарды вариантов паролей в секунду для хешей bcrypt или SHA-256, поэтому слабые и распространённые пароли восстанавливаются без труда.

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

Усиление защиты паролей на стороне сервера (надёжное хеширование, добавление соли, ограничение частоты запросов) не защищает от фишинга. Когда пользователь вводит пароль на поддельном сайте, злоумышленник напрямую получает пароль в открытом виде, независимо от того, насколько хорошо легитимный сервер его хранит. Сегодня фишинг является основным способом кражи учётных данных.

Базы данных с миллиардами пар «имя пользователя/пароль», полученных в результате прошлых утечек, доступны в теневом вебе. Злоумышленники используют автоматизированные инструменты, чтобы проверять эти учётные данные в финансовых организациях, интернет-магазинах и почтовых сервисах в промышленных масштабах. Атака оказывается успешной, если пользователь повторно использовал пароль, который уже был скомпрометирован.

При традиционной парольной аутентификации сервер неизбежно узнаёт пароль пользователя в открытом виде во время входа (пусть даже на короткое время, до хеширования). Это означает, что каждому оператору сервера нужно полностью доверять: он не должен неправомерно использовать учётные данные, записывать их в журнал или случайно раскрывать. На практике такая гарантия встречается редко.

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

Доказательства с нулевым разглашением предоставляют теоретическую основу для этого: доказывающая сторона может убедить проверяющую сторону в истинности секрета, не раскрывая сам секрет. Протоколы парольной аутентификации, такие как SRP и OPAQUE, применяют эти принципы, обеспечивая аутентификацию без непосредственной передачи пароля и его хранения на стороне сервера.

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

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

Современные решения включают SRP (безопасный удалённый пароль), OPAQUE и FIDO2/ключи доступа. Каждое из них решает разные аспекты фундаментальной проблемы. SRP и OPAQUE устраняют необходимость знать пароль на стороне сервера. FIDO2 и ключи доступа полностью устраняют пароли, используя криптографию с открытым ключом, привязанную к конкретному источнику.

Какую атаку НЕ предотвращает надёжное хеширование паролей на стороне сервера (например, bcrypt)?

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