Аппаратные ключи

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

Аппаратные ключи поддерживают обнаруживаемые учётные данные — функцию, где веб-сайты могут запросить имя пользователя вместо того, чтобы вводить его вручную. Она становится всё популярнее среди разработчиков, но имеет ограничения: 25–100 аккаунтов на аппаратный ключ, а топовые модели вмещают до 300. Превысив лимит, нужно либо удалить существующие аккаунты, либо купить дополнительный набор ключей.

Синхронизированные passkeys

Apple и Google хотят привязать личность пользователя к своим операционным системам. На их устройствах рекомендуемый путь — использовать синхронизированное управление passkeys через Apple или Google аккаунт. Если автоматизированные системы одного дня заблокируют аккаунт, пользователь необратимо потеряет доступ ко всем passkeys, используемым на сторонних сайтах.

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

Passkeys в менеджерах паролей

При хранении passkeys в менеджере паролей вроде Bitwarden или KeePassXC приходится бороться с платформой. Хотя операционные системы недавно добавили API (например, Credential Manager на Android) для интеграции сторонних инструментов, опыт остаётся фрагментарным и уступает десятилетиям отработки UX автозаполнения паролей. Особенно нестабильно автозаполнение вне браузера и в нативных приложениях. В будущем сторонние passkeys могут стать стандартом, но пока мы до этого не доросли.

Когда passkeys не работают

Логин в собственные аккаунты с личных устройств — идеальный сценарий для passkeys. Когда нужно работать с чужим компьютером — это становится неудобно. Можно подключить аппаратный ключ, но не всегда есть доступ к нужным портам. Можно войти с синхронизированным passkey, но это потребует доверить компьютеру — тот не будет утечен со всеми остальными passkeys. Последний вариант — «Hybrid Transport», когда сканируется QR-код и одновременно устанавливается Bluetooth-соединение. Хотя это безопасно и работает в теории, на практике сталкиваются со множеством граничных случаев: сбои соединения, несоддержка Bluetooth.

Passkeys ещё не готовы

Корпоративным пользователям есть веские причины использовать passkeys, но экосистема для отдельных людей пока недостаточно зрела.

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