Вход без пароля: как работают passkeys и WebAuthn
Вход без пароля: как работают passkeys и WebAuthn
Passkey позволяет входить по отпечатку, лицу или PIN-коду без передачи пароля сайту. Как WebAuthn проверяет пользователя и почему такой вход сложнее украсть через фишинг?
Пароля нет, но проверка пользователя осталась
Вход без пароля сначала выглядит почти подозрительно. Сайт предлагает приложить палец к датчику, посмотреть в камеру или ввести PIN-код устройства — и сразу открывает аккаунт. Никакой длинной комбинации символов, SMS и кода из приложения.
Может показаться, что отпечаток пальца отправляется на сервер вместо пароля. На самом деле биометрические данные сайт вообще не получает. Проверка происходит внутри устройства, а серверу отправляется криптографическое доказательство.
За этим сценарием стоят две связанные технологии: passkeys хранят учётные данные, а WebAuthn определяет, как сайт работает с ними через браузер.
Passkey и WebAuthn — не одно и то же
Passkey — это учётные данные, построенные на паре криптографических ключей. Закрытый ключ хранится у пользователя: на телефоне, компьютере, аппаратном ключе безопасности или у провайдера, который синхронизирует passkeys между устройствами.
Открытый ключ передаётся сайту и сохраняется рядом с аккаунтом. С его помощью сервер может проверить цифровую подпись, но не способен создать её самостоятельно.
WebAuthn — браузерный API, через который сайт просит создать такие учётные данные или подтвердить вход. Основных операций всего две: navigator.credentials.create() для регистрации и navigator.credentials.get() для аутентификации.
Есть ещё аутентификатор — компонент, который фактически хранит ключ и подписывает запрос. Им может быть сам смартфон, системное хранилище компьютера или отдельный USB-ключ.
Как создаётся passkey?
Обычно пользователь уже находится в аккаунте и выбирает в настройках пункт создания passkey. Сервер формирует параметры регистрации и генерирует случайный challenge — одноразовый набор байтов, который нельзя предсказать заранее.
Frontend получает эти параметры и передаёт их WebAuthn:
const response = await fetch(«/api/passkeys/register/options», { method: «POST» }); const optionsJSON = await response.json(); const publicKey = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON); const credential = await navigator.credentials.create({ publicKey }); await fetch(«/api/passkeys/register/verify», { method: «POST», headers: { «Content-Type»: «application/json» }, body: JSON.stringify(credential.toJSON()) });
После вызова create() браузер обращается к доступному аутентификатору. Устройство просит пользователя подтвердить действие отпечатком, лицом, PIN-кодом или другим настроенным способом.
Затем аутентификатор создаёт уникальную пару ключей для этого сайта. Открытый ключ вместе с идентификатором credential возвращается серверу. Закрытый ключ сайту не передаётся.
Сервер проверяет ответ и связывает новый credential с аккаунтом. С этого момента пользователь может подтверждать вход с помощью соответствующего закрытого ключа.
Что происходит во время входа?
Аутентификация начинается почти так же. Сервер снова создаёт одноразовый challenge и передаёт браузеру параметры запроса.
const response = await fetch(«/api/passkeys/login/options», { method: «POST» }); const optionsJSON = await response.json(); const publicKey = PublicKeyCredential.parseRequestOptionsFromJSON(optionsJSON); const credential = await navigator.credentials.get({ publicKey }); await fetch(«/api/passkeys/login/verify», { method: «POST», headers: { «Content-Type»: «application/json» }, body: JSON.stringify(credential.toJSON()) });
Устройство находит подходящий passkey и после подтверждения пользователя подписывает challenge закрытым ключом. Сервер получает подпись и проверяет её через сохранённый открытый ключ.
Если подпись правильная, challenge совпадает, а остальные параметры прошли проверку, сервер создаёт обычную пользовательскую сессию. Дальше приложение может использовать cookie или токен так же, как после входа по паролю.
Passkey меняет способ подтверждения личности, но не отменяет управление сессиями. Если приложение неправильно защищает cookie, новый способ входа сам по себе ситуацию не исправит.
Почему старую подпись нельзя использовать повторно?
Challenge нужен для защиты от повторного воспроизведения запроса. Если злоумышленник перехватит корректный ответ WebAuthn, отправить его ещё раз не получится: при следующем входе сервер создаст новое случайное значение.
Challenge должен генерироваться на сервере, иметь достаточную случайность, временно сохраняться и приниматься только один раз. Клиентская генерация здесь не подходит — браузеру нельзя доверять принятие серверных решений.
Во время проверки сервер сравнивает полученный challenge с ранее созданным. Если значения отличаются или запрос уже использовался, вход отклоняется.
На фронтенде всё выглядит как один вызов navigator.credentials.get(), но настоящая безопасность находится в серверной проверке ответа.
Почему passkeys защищают от фишинга?
Пароль можно ввести почти в любую форму. Если поддельный сайт выглядит убедительно, человек сам отправляет злоумышленнику секрет, который затем используется на настоящем сервисе.
Passkey привязан к конкретному RP ID — обычно домену сайта. Credential, созданный для example.com, нельзя применить на examp1e.com или другом похожем адресе.
Браузер проверяет происхождение страницы и не предложит чужому домену нужный passkey. Пользователю не приходится визуально определять, настоящая ли перед ним форма входа. Это делает WebAuthn устойчивым к привычному сценарию фишинга.
Ещё одно преимущество — отсутствие повторного использования. Для каждого сервиса создаётся отдельная пара ключей. Утечка данных одного сайта не открывает доступ к аккаунтам на других ресурсах.
Что получит злоумышленник после взлома базы?
При обычной аутентификации сервер хранит хеши паролей. Хорошо настроенное хеширование сильно усложняет восстановление исходных значений, но слабые и повторно используемые пароли всё равно могут быть подобраны.
При использовании passkeys сервер хранит открытые ключи. Они изначально не являются секретными и не позволяют создавать правильные подписи.
В базе также сохраняются идентификатор credential, связь с аккаунтом и служебные данные, необходимые для проверки. Эту информацию всё равно нужно защищать, но её кража не даёт готового средства для входа.
Это одно из самых сильных отличий от паролей: серверу больше не приходится хранить материал, который пользователь сможет предъявить как секрет.
Отпечаток пальца не отправляется сайту
Биометрия используется устройством, чтобы разрешить работу с закрытым ключом. Сайт получает результат криптографической операции, а не изображение лица или данные отпечатка.
Вместо биометрии может использоваться PIN-код устройства. Поэтому фраза «войти по лицу» описывает пользовательский интерфейс, но не сам протокол. Для сервера важна успешно выполненная проверка пользователя аутентификатором.
Это также означает, что сайт не выбирает конкретный способ подтверждения. Доступные варианты зависят от устройства, операционной системы, настроек и используемого passkey-провайдера.
Биометрическая проверка не доказывает сайту личность человека в юридическом смысле. Она подтверждает, что аутентификатор разрешил использовать ключ после локальной проверки.
Passkey может храниться на одном или нескольких устройствах
Существуют синхронизируемые и привязанные к устройству passkeys. В первом случае провайдер защищённо переносит credential между устройствами пользователя. После покупки нового телефона passkeys могут появиться на нём вместе с остальными данными аккаунта.
Device-bound passkey остаётся на конкретном устройстве или аппаратном ключе безопасности. Такой вариант уменьшает зависимость от облачной синхронизации, но требует внимательнее продумать резервный доступ.
Нельзя сказать, что один вариант всегда правильный. Для обычного пользовательского сервиса удобство синхронизации часто важнее. Для административного аккаунта или системы с высоким уровнем риска может понадобиться аппаратный ключ.
Я бы не заставлял всех пользователей разбираться в этих различиях при первом входе. Интерфейс должен показать простое действие, а расширенное управление ключами можно оставить в настройках безопасности.
Как войти на чужом компьютере?
Если passkey находится на телефоне, это не означает, что вход возможен только с него. Современные реализации поддерживают cross-device authentication.
На компьютере пользователь выбирает вход с другого устройства, сканирует QR-код телефоном и подтверждает действие. Устройства проверяют физическую близость, после чего телефон подписывает запрос своим ключом.
Закрытый ключ при этом не переносится в браузер чужого компьютера. Телефон выступает внешним аутентификатором и подтверждает конкретный вход.
Сценарий удобный, но его обязательно нужно проверять на реальных устройствах. Эмуляция в одном браузере не показывает, насколько понятными окажутся QR-код, выбор провайдера и системные окна для обычного пользователя.
Курс изучения JavaScript
Можете пройти наш бесплатный курс по изучению JavaScript
Можно ли убрать поле с email?
Passkeys могут быть discoverable credentials. В таком случае браузер или аутентификатор сам находит аккаунты, связанные с доменом, и предлагает пользователю нужный вариант.
Серверу не обязательно заранее получать email, чтобы определить список credentials. После подписи он использует возвращённый userHandle или идентификатор credential и находит аккаунт.
Так появляется настоящий вход без имени пользователя и пароля. Человек открывает страницу, выбирает сохранённый аккаунт и подтверждает действие.
Есть и другой режим: пользователь сначала вводит email, а сервер возвращает список credentials, связанных с конкретным аккаунтом. Такой переход проще добавить в существующую систему, но поле логина остаётся.
Оцените материал:
