Существует множество источников, в которых говорится, что FIDO2 / CTAP2 обратно совместим с U2F:
... все ранее сертифицированные ключи безопасности FIDO U2F и YubiKeys будут продолжать работать в качестве входа для аутентификации второго фактора опыт работы с веб-браузерами и онлайн-сервисами, поддерживающими WebAuthn. - Юбико
Но после просмотра спецификаций у меня возникают проблемы с пониманием того, как это на самом деле работает на практике. В частности, похоже, что существует несоответствие между идентификатором проверяющей стороны FIDO2 и идентификатором приложения U2F .
В U2F идентификатор приложения URL, например https://example.com. SHA-256 идентификатора приложения называется параметр приложения . прикладной параметр - это то, что фактически отправляется аутентификатору во время регистрации и аутентификации.
В FIDO2 эквивалентом является идентификатор проверяющей стороны , который определен быть доменным именем, например example.com.
* Идентификатор проверяющей стороны и идентификационный номер приложения служат одной и той же цели как в FIDO2 / CTAP2, так и в U2F. Однако аутентификаторы CTAP2 получают идентификатор проверяющей стороны напрямую в виде строки UTF8, тогда как аутентификаторы U2F получают только SHA-256 га sh идентификатора приложения (приложения параметр ).
Документация FIDO для CTAP описывает , как CTAP2 отображается на CTAP1 / U2F . В нем они просто обрабатывают идентификатор проверяющей стороны напрямую как идентификатор приложения :
Пусть rpIdHa sh будет байтовым массивом размером 32, инициализированным с SHA-256 га sh параметра rp.id в качестве параметра приложения CTAP1 / U2F (32 байта)
Это кажется противоречивым , Допустим, я был example.com, и я принял аутентификацию второго фактора U2F на ранней стадии. Мой идентификатор приложения будет https://example.com, поэтому мой исходный параметр приложения U2F будет SHA256("https://example.com"):
100680ad546ce6a577f42f52df33b4cfdca756859e664b8d7de329b150d09ce9
Но если я затем переключусь на использование Webauthn, мой идентификатор проверяющей стороны будет просто example.com. Когда он преобразуется в параметр приложения U2F , как описано в разделе раздела fido-client-to-authenticator-protocol-v2.0 , результирующее значение должно быть SHA256("example.com"):
a379a6f6eeafb9a55e378c118034e2751e682fab9f2d30ab13d2125586ce1947
Это явно другое. Любой, кто ранее настроил свои ключи U2F для использования на моем веб-сайте, больше не сможет использовать их после того, как я перешел на WebAuthn: если они не перерегистрируют свои ключи. И, конечно, для этого им понадобится войти в систему.
Копая глубже, я заметил, что приведенный в документации пример содержит идентификатор проверяющей стороны из example.com, но га sh, которые они дали в примере, было ...
1194228DA8FDBDEEFD261BD7B6595CFD70A50D70C6407BCF013DE96D4EFB17DE
Что не является или из двух вышеупомянутых вариантов. Мне остается неясным, какая строка хэширует это значение.
Так что я здесь не так делаю? Как могли сервисы, которые развернули 2FA с использованием U2F, когда-либо переключиться на FIDO2 / Webauthn, не требуя от своих пользователей перерегистрации своих ключей безопасности? Я должно быть что-то упустил.