Когда большинство людей думают о криптографии, первым делом приходит на ум шифрование: сохранение конфиденциальности информации. Но не менее важно (если не важнее) — подлинность: гарантия того, что информация действительно исходит от аутентичного источника. Когда вы посещаете веб-сайт, сервер обычно доказывает свою личность с помощью сертификата Transport Layer Security (TLS), подтверждённого инфраструктурой открытых ключей веба (Web PKI). Пароли — традиционное решение для аутентификации пользователей, но они страдают от фишинга и утечек данных. Здесь и появляются пасскеи.

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

Основы криптографии пасскеев

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

С криптографической точки зрения всё достаточно прямолинейно. Закрытый ключ аутентифицирует пользователя, но на сервер не передаётся никакая чувствительная информация, полезная для атакующего. Если серверный вызов сгенерирован корректно — например как равномерно случайная последовательность из 32 байт — он предотвращает атаки повторного воспроизведения. Поскольку сервер хранит только открытый ключ, а пользователь не отправляет ему чувствительную информацию, в случае взлома утекать нечему.

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

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

WebAuthn — основная спецификация пасскеев. Проще говоря, пользователи обращаются к веб-сайту (доверяющей стороне) через браузер (пользовательский агент WebAuthn) на устройстве — ноутбуке, телефоне или ПК (клиентское устройство). Браузер взаимодействует с аутентификатором — программным или аппаратным компонентом, который генерирует пару ключей пасскея и создаёт цифровые подписи с её помощью.

На схеме выше показано, как работает аутентификация пасскеем:

1. Веб-сайт запрашивает аутентификацию через браузер.

2. Браузер взаимодействует с аутентификатором.

3. Аутентификатор проверяет учетные данные и присутствие пользователя.

4. Аутентификатор возвращает подписанный ответ.

5. Браузер пересылает этот ответ веб-сайту для проверки.

Это упрощённое описание. Спецификация WebAuthn допускает гораздо более широкий набор сценариев (например, всё может работать через мобильное приложение вместо связки веб-сайт/браузер). Однако эти детали несущественны для понимания криптографической стороны пасскеев.

Защита от фишинга

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

Это означает, что если вы создаёте пасскей для bank.com, фишинговый сайт на fake-bank.com не сможет его использовать — ваш аутентификатор отклонит запрос. Кроме того, для каждого веб-сайта создаётся уникальная пара ключей, что полностью устраняет проблему повторного использования паролей.

Дополнительно спецификация допускает только origins, использующие HTTPS, что означает, что запрос исходит от сервера с действительным сертификатом для соответствующего origin.

Типы аутентификаторов

В общем случае аутентификаторы — это «то, что у вас есть». Все аутентификаторы могут проверять фактическое присутствие пользователя при аутентификации. Некоторые аутентификаторы дополнительно могут проверять пользователя по принципу «то, что он знает» (например, PIN-код) или «то, чем он является» (биометрия).

Существуют два основных типа аутентификаторов, с которыми вы столкнётесь:

Платформенные аутентификаторы: находятся непосредственно в пользовательском устройстве.
Примеры: iCloud Keychain, Google Password Manager, Windows Hello, 1Password.
Плюсы: удобны, часто поддерживают облачное резервное копирование.
Минусы: уязвимы, если компрометировано само устройство.

Переносные аутентификаторы (roaming): отдельные специализированные аппаратные устройства.
Примеры: YubiKey, Titan Security Key, ключи Feitian.
Плюсы: более высокая изоляция безопасности, не зависят от компрометации устройства.
Минусы: их можно потерять или повредить, обычно нет механизма резервного копирования.

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

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

Когда пользователь регистрирует пасскей на веб-сайте, аутентификатор генерирует пасскей и идентификатор (credential ID). Веб-сайт хранит открытый ключ и идентификатор и связывает их с учётной записью пользователя. Затем веб-сайт может использовать этот идентификатор, чтобы указать аутентификатору, к какому пасскею он хочет обратиться. У некоторых аутентификаторов много памяти, и они хранят все пасскеи пользователя у себя. Другие — нет, поэтому они шифруют пасскей и при регистрации передают зашифрованный пасскей веб-сайту в качестве идентификатора. Когда веб-сайту нужно аутентифицировать пользователя, он передаёт идентификатор браузеру, тот — аутентификатору, который расшифровывает его и использует пасскей. По сути, веб-сайт хранит пасскей, но поскольку он зашифрован, в случае взлома его ценность ограничена.

Теоретически можно просто хранить пару криптографических ключей в файле, написать вокруг неё ПО, выполняющее криптографические операции, и «сделать вид», что это аутентификатор. Но как веб-сайты узнают, что их пользователи используют безопасные аутентификаторы? Аутентификаторы могут криптографически доказать некоторые факты о своём происхождении, например производителя, сформировав аттестационное утверждение при создании пользователем пасскея. Это утверждение подкреплено цепочкой сертификатов, подписанной производителем. Особенно полезно для корпоративных пользователей, поскольку позволяет компании гарантировать, что все используют конкретные аутентификаторы, удовлетворяющие требованиям безопасности. Однако аттестация опциональна: спецификация WebAuthn не требует её поддержки аутентификаторами.

Наконец, как и с любым фактором «то, что у вас есть», важный вопрос: что происходит, если вы его потеряете или он выйдет из строя? В общем случае потеря аутентификатора означает потерю всех контролируемых им пасскеев. Поскольку пасскеи — это по сути случайно сгенерированные пары криптографических ключей, надежды на восстановление нет. Большинство платформенных аутентификаторов, таких как iCloud Keychain, Google Password Manager и 1Password, позволяют создавать резервные копии пасскеев, синхронизируя их в облако. Но это всегда компромисс: восстанавливаемые пасскеи имеют большую поверхность атаки, поскольку злоумышленники могут попытаться получить пасскей через механизм восстановления. В целом важно, чтобы веб-сайты имели механизм восстановления для случаев утраты пользователями доступа к своим пасскеям, помня при этом, что атакующие могут нацелиться на сам механизм восстановления.

Хотя использование платформенных аутентификаторов с возможностями резервного копирования снижает риск потери пасскеев, оно его не устраняет. Пользователи, заблокированные на платформе, потеряют доступ к своим пасскеям, платформа может случайно удалить пасскеи. Кроме того, платформы поддерживают совместное использование пасскеев или семейные аккаунты, где несколько пользователей могут иметь доступ к одним и тем же пасскеям. Веб-сайт должен предупреждать пользователей об этих рисках в зависимости от того, какой доступ предоставляет пасскей.

Модели угроз

Вопреки маркетинговым заявлениям, пасскеи — не «серебряная пуля» безопасности. Посмотрим, от чего они действительно защищают.

Модель угроз пасскеев показывает, что они защищают от тех угроз, от которых обычно защищают пароли, и при этом устраняют риск фишинга и повторного использования паролей. Это существенное улучшение! Раздел Conformance спецификации WebAuthn делает очень сильное заявление, подразумевая, что веб-сайты, браузеры и аутентификаторы, соответствующие спецификации, «безопасны» от злонамеренного поведения.

Это утверждение чрезмерно упрощает реальность безопасности. Ниже — реальные сценарии атак, которые всё ещё возможны:

Атаки через браузер: Некоторые аутентификаторы (например, YubiKey 5C) не имеют встроенного экрана и полностью полагаются на браузер для отображения сайта, на котором вы аутентифицируетесь. Если ваш браузер скомпрометирован вредоносным ПО или расширением, он может показывать вам «attacker.com», тогда как фактически отправит вашему аутентификатору запрос на подпись для «google.com».
Компрометация аутентификатора: Безопасность пасскеев зависит от того, как аутентификатор защищает закрытые ключи. Поддельный аппаратный ключ, вредоносная программа, маскирующаяся под встроенный аутентификатор вашей ОС, могут тайно извлекать ваши закрытые ключи. Представьте покупку устройства, похожего на YubiKey, у ненадёжного продавца — возможно, оно отправляет копии ваших ключей третьим лицам.

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

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

Почему это важно? Когда пользователь регистрирует пасскей, веб-сайт хранит credential ID как идентификатор пасскея этого пользователя. Если атакующему удастся каким-то образом зарегистрировать пасскей с тем же credential ID, что и у целевой жертвы, он может вызвать путаницу в аутентификации.

Это может показаться маловероятным, но рассмотрите такие сценарии:

Атакующий, знающий credential ID жертвы (например, перехваченный из сетевого трафика), может попытаться зарегистрировать свой пасскей с тем же ID.
Вредоносное приложение-аутентификатор может умышленно генерировать дублирующиеся credential ID вместо соблюдения требований случайности протокола.
Ошибки реализации могут снижать эффективную случайность генерации credential ID.

Исправление простое: веб-сайты всегда должны отклонять попытки регистрации, когда credential ID нового пасскея совпадает с уже имеющимся в базе. Это создаёт простую защиту «первый пришёл — первый обслужен» против конфликтов credential ID.

Расширения

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

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

Одно из таких — prf (семейство псевдослучайных функций), построенное поверх расширения hmac-secret, определённого в спецификации FIDO CTAP v2.1. С расширением prf аутентификатор может вычислять HMAC-SHA-256, используя фиксированный случайно сгенерированный 32-байтовый HMAC-ключ. Входом для вычисления HMAC является дайджест SHA-256 от фиксированного префикса WebAuthn, за которым следует вход, предоставленный веб-сайтом. Хотя это расширение недостаточно гибко, чтобы реализовать, скажем, HKDF, с его помощью можно реализовать стадию HKDF Extract2.

Итак, используя эти расширения, можно выводить или хранить статические криптографические ключи. Однако, как и со всей криптографией в контексте браузера, чрезвычайно сложно, если вообще возможно, добиться подлинной «end-to-end» безопасности. Обычно это требует устойчивости системы к злонамеренному серверу. Веб-криптография исполняется JavaScript-кодом, обслуживаемым сервером, а это значит, что злонамеренный сервер может просто отдать вредоносный JavaScript, извлекающий ключи, отправляющий расшифрованные сообщения обратно на сервер и т. п. Ещё хуже, что злонамеренный сервер может делать это адресно: отдавать корректный JavaScript большинству пользователей, но вредоносный — конкретной цели. Реализация Subresource Integrity для кода в вебе (например, хранение хэша всех опубликованных версий у доверенной третьей стороны) и техники «бинарной прозрачности» (публично проверяемый, защищённый от подмены журнал) — две многообещающие меры против такого рода угроз.

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

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

Дальнейший путь для пасскеев

Время внедрять пасскеи — сейчас. Криптографические основы пасскеев обеспечивают сильные гарантии безопасности, которые делают их очевидным выбором по умолчанию для современных систем аутентификации при корректной реализации на базе WebAuthn. Хотя это не идеальное средство безопасности, пасскеи устраняют многие критические уязвимости, десятилетиями преследовавшие пароли: пасскеи никогда не передают чувствительную информацию на серверы, не могут быть повторно использованы на разных сайтах и противостоят фишингу благодаря привязке к origin.

Рекомендации для пользователей и разработчиков

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

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