Аутентификация без паролей — возможно ли это и как: Google о своих новых проектах

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

Как прийти к этому миру без паролей и какие проекты для этого разрабатывает Google, на конференции Google I/O 2022 рассказал Эджи Катамура, Developer Advocate в Google. Highload публикует главное из этого материала.

WebAuthn — аутентификация с реальным ключом

Web Authentication, или WebAuthn — это веб стандарт, который позволяет пользователям аутентифицироваться через FIDO-совместимое устройство, или аутентификатор. 

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

Как работает WebAuthn

В WebAuthn есть три участника:

1. фронтенд сайта;
2. веб-сервер;
3. аутентификатор.

Сначала пользователь должен зарегистрировать аутентификатор на сайте — после первого входа в систему или во время создания учетной записи. Для этого веб-сайт сначала получает вызов от сервера, а затем вызывает navigator.credentials.create. В этот момент в браузере отображается диалоговое окно WebAuthn и аутентификатор предлагает пользователю буквально нажать на ключ.

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

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

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

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

Альтернатива ключам

Ключи безопасности — отличный выбор для учетных записей с высоким уровнем риска или в корпоративных условиях. Для обычных пользователей есть вариант проще — использовать Platform Authenticators, которые уже встроены в смартфоны и компьютеры. То есть датчики отпечатков пальцев и камеры с функцией распознавания лиц.

Чтобы использовать Platform Authenticator с WebAuthn, нужно прописать это в коде (authenticatorAttachment: ‘platform’, userVerification: ‘required’). В остальном схема работы будет такая же.

При работе с Platform Authenticators нужно учитывать две их особенности:

1. В текущей реализации FIDO для аутентификации пользователя необходим список идентификаторов учетных данных. То есть нужно попросить пользователя предоставить его имя пользователя перед аутентификацией.
2. Поскольку Platform Authenticators встроены в устройство, их можно использовать только на одном устройстве.

Вот какие решения этих проблем предлагает Google:

#1 Решение проблемы с именем пользователя

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

В будущем вы также сможете создать быструю форму подписи, в которой будет всего одна кнопка, вызывающая WebAuthn. Эта функция уже поддерживается в Chrome и других браузерах, а в конце этого года появится и в Android.

Чтобы использовать обнаруживаемые учетные данные, передайте пустой объект allowCredentials при аутентификации.

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

#2 Решение проблемы с одним устройством

Для этого есть одно слово — passkeys. Это аналог паролей, но только passkeys являются учетными данными FIDO. В Chrome они синхронизируются на всех устройствах Android-пользователя.

Например, если пользователь создает ключ доступа на веб-сайте на одном устройстве Android, этот же ключ доступен и на другом устройстве Android, при условии, что пользователь зашел через тот же аккаунт Google.

От веб-разработчиков не требуется никаких дополнительных действий для активации этой функции на WebAuthn.

Поскольку passkeys основаны на стандарте FIDO, другие платформы (например, Apple) уже разрабатывают аналогичные функции. Если же говорить о Windows, то, если пользователь хочет войти в систему с компьютера, он может это сделать. Для этого нужно отсканировать QR-код, выбрать учетную запись и пройти аутентификацию через телефон.

При этом авторизация по QR-коду требуется только один раз. В последующие входы пользователь может просто выбирать имя телефона из списка обнаруживаемых учетных данных.

Passkeys на Android будет доступен позже в 2022 году.

Как защитить сайт, работающий только с паролями

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

Использование одноразового пароля

Самый надежный вариант — использовать аутентификатор FIDO. Альтернативный вариант — попросить пользователя ввести одноразовый пароль (OTP) и отправить его по SMS или email.

Для оптимизации работы можно использовать WebOTP API в Chrome и автозаполнение одноразового кода в Safari. В этом случае нужно специально отформатировать SMS, чтобы OTP заполнялся автоматически.

Identity federation

Еще одним надежным вариантом аутентификации является identity federation. Он состоит из стандартных протоколов, таких как OpenID Connect, OAuth или SAML. При использовании identity federation доверяющая сторона (Relying Party, RP) может делегировать свой механизм аутентификации для входа пользователей в систему поставщику идентичностей (Identity Provider, IdP)

Например, многие из вас наверняка регистрировались на разных веб-сайтах через учетную запись Google. Именно так и работает identity federation.

Проблема этого способа в том, что IdP могут узнать, какие RP посещает пользователь. Поэтому Google сейчас работает над новым API для браузера с функцией identity federation — Federated Credential Management API (FedCM).

Вот как он будет работать.

Допустим, ваш сайт — это RP. Как только пользователь заходит на сайт, если он уже подписан в IdP, появляется диалоговое окошко. Нажав на кнопку «Продолжить как», пользователь создает федеративную учетную запись и входит на сайт под своей идентификацией, предоставленной IdP.

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

Проект FedCM все еще находится на ранней стадии, но уже нуждается в обратной связи. Узнать больше о FedCM и стать участником бета-версии браузера можно тут.