Тонкости passkeys. Разбираем сильные и слабые стороны нового способа аутентификации

БиблиотекаБиблиотека

2025

Криптография — это не только шифрование, но и подлинность. Пароли уязвимы для фишинга и утечек — на помощь приходят passkeys (ключи доступа). Разбор криптографических механизмов под капотом (по мотивам поста The cryptography behind passkeys из блога Trail of Bits).

Основы. Passkey — пара криптографических ключей: публичный и приватный. Сайт хранит только публичный ключ и идентификатор; при входе сайт отправляет вызов (например, случайные 32 байта — защита от перебора), который подписывается приватным ключом, — при верной подписи вход разрешается. На сервер не уходит ничего полезного взломщику: сервер взломан — утечки нет.

WebAuthn. Одних цифровых подписей недостаточно против фишинга (можно уговорить подписать что-то от имени другого сайта или переиспользовать одну пару на нескольких сайтах) — поэтому passkeys построены на спецификации WebAuthn от W3C. Роли: сайт (relying party) — браузер (WebAuthn user agent) — аутентификатор (железо или программа, генерирующая пару и подписи). Схема: сайт запрашивает авторизацию → браузер связывается с аутентификатором → тот проверяет пользователя → возвращает подписанный ответ → браузер отправляет его сайту. Взаимодействие браузер↔аутентификатор описано протоколом CTAP от FIDO Alliance; всё может работать и в мобильном приложении.

Защита от фишинга — привязка к источнику. Браузеры обязаны сообщать аутентификатору домен сайта; аутентификатор использует passkey только если домен запроса совпадает с доменом создания ключа: ключ для bank.com не сработает на fake-bank.com. Каждому сайту — своя уникальная пара ключей (нет переиспользования паролей). Допускаются только источники по HTTPS (сервер с действительным сертификатом).

Виды аутентификаторов (“что-то, что у тебя есть”; некоторые проверяют PIN или биометрию — “что-то, что ты знаешь/ты есть”):

Платформенные — внутри гаджета (iCloud Keychain, Google Password Manager, Windows Hello, 1Password): удобство, облачное резервное копирование; минус — уязвимы при компрометации девайса.
Переносные — специализированные устройства (YubiKeys, Titan, Feitian): максимальная защита и устойчивость к взлому устройства; минус — легко потерять/сломать, бэкапа обычно нет.

Платформа с Bluetooth может работать как переносная; для суперважных приложений лучше аппаратные ключи. Проверяй детали запроса (домен) перед одобрением — их показывает аутентификатор или браузер.

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

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

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

Модель угроз. Passkeys защищают от тех же угроз, что пароли, плюс устраняют фишинг и переиспользование. Остаются реальные атаки:

через браузер: аутентификаторы без дисплея (YubiKey 5C) полагаются на браузер — малварь или вредоносное расширение может показывать “google.com”, подписывая запрос для “attacker.com”;
скомпрометированные аутентификаторы: поддельный ключ, заражённое ПО или малварь, изображающая встроенный аутентификатор ОС, могут тайком вытаскивать приватные ключи (якобы YubiKey от ненадёжного продавца может рассылать копии ключей);
при малвари/спайваре на девайсе passkeys не спасут, но работают как ограничители атаки (каждая подпись — отдельное взаимодействие с аутентификатором); не защищают и от тех, кто контролирует домен сайта.

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

Расширения WebAuthn (опциональны; стандартные — в спецификации, дополнительные — в реестре IANA):

PRF (на базе hmac-secret из FIDO CTAP v2.1): аутентификатор вычисляет HMAC-SHA-256 с фиксированным случайным 32-байтовым ключом; недостаточно гибка для полного HKDF, но реализует HKDF Extract — получение стойкого ключа из нестабильного источника.
Large Blob: хранение блоба непрозрачных данных (сертификаты, криптографические ключи), которые сайт читает/пишет во время проверки подлинности.

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

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

Это краткая аннотация статьи, полную версию читайте в первоисточнике.

Читать полную версию

Первоисточник: Журнал “Хакер” (xakep.ru), 2025

Эксперт: Редакционный эксперт