FIDO2: WebAuthn, claus d'accés i seguretat (CA)

FIDO2 comprèn dos estàndards d'autenticació de clau pública: l'API d'autenticació web (WebAuthn) del World Wide Web Consortium i el protocol de client a autenticador (CTAP) de la FIDO Alliance. Junts, permeten a una part dependent registrar i utilitzar una credencial criptogràfica sense emmagatzemar un secret compartit reutilitzable com una contrasenya.

FIDO2 pot proporcionar autenticació resistent al phishing i a la repetició quan s'implementa i es valida correctament. No demostra la identitat legal d'una persona, no decideix qui hauria de poder registrar-se, no assegura una sessió de servidor compromesa ni repara un procés de recuperació de compte feble. Aquests són controls adjacents que s'han de dissenyar al voltant de la cerimònia d'autenticació.

Punts clau

• FIDO2 és WebAuthn més CTAP. WebAuthn connecta un lloc web o aplicació al client; CTAP connecta la plataforma client a un autenticador itinerant.
• La clau privada es queda amb l'autenticador. La part dependent emmagatzema una clau pública i verifica les signatures sobre nous desafiaments i context delimitat.
• La vinculació de dominis crea resistència al phishing. Una credencial registrada per a un identificador de part dependent no es pot simplement repetir al domini no relacionat d'un atacant.
• Les claus d'accés són credencials FIDO. Poden estar vinculades al dispositiu o sincronitzades entre els dispositius d'un proveïdor, creant diferents compromisos d'assegurament, recuperació i portabilitat.
• La recuperació forma part del model de seguretat. Un inici de sessió FIDO2 fort es pot eludir si el correu electrònic, el suport o les rutes de recuperació d'identitat poden reemplaçar la credencial amb proves més febles.

Què és FIDO2?

La visió general de les especificacions de la FIDO Alliance defineix FIDO2 com la combinació de l'especificació W3C WebAuthn i els protocols de client a autenticador de FIDO. Els estàndards divideixen el sistema en rols cooperatius:

• Part dependent: el lloc web o servei que registra credencials i verifica les asseveracions d'autenticació.
• Client: normalment el navegador o el component del sistema operatiu que implementa WebAuthn i media la cerimònia.
• Autenticador: un component de plataforma o dispositiu extern que crea i utilitza la clau de la credencial.
• Usuari: la persona que consent el registre o l'autenticació i pot verificar localment amb un PIN, contrasenya o biometria.

L'especificació W3C WebAuthn Level 3 defineix una API web per crear i utilitzar credencials de clau pública delimitades a una part dependent. Els scripts mai reben la clau de credencial privada. Reben dades estructurades i proves criptogràfiques produïdes a través de l'autenticador i el client.

Comparació de FIDO2, WebAuthn, CTAP, U2F i claus d'accés

Terme	Significat pràctic	Límit principal
FIDO2	Els estàndards WebAuthn i CTAP utilitzats junts	Família d'estàndards completa, no una sola trucada a l'API
WebAuthn	API del navegador o del client i model de dades de la part dependent per a credencials de clau pública	Connecta la part dependent al client
CTAP2	Protocol entre la plataforma client i un autenticador itinerant	Transporta la comunicació de l'autenticador extern a través de transports com USB, NFC i BLE
U2F / CTAP1	Protocol FIDO anterior comunament associat amb claus de seguretat de segon factor	Més limitat que les capacitats modernes de FIDO2
Clau d'accés	Una credencial FIDO detectable dissenyada per a l'inici de sessió sense contrasenya	Es pot sincronitzar o vincular al dispositiu
Clau de seguretat	Un autenticador de maquinari itinerant connectat per USB, NFC o un altre transport compatible	Una possible forma d'autenticador
Autenticador de plataforma	Autenticador integrat en un dispositiu o sistema operatiu	Sovint s'activa amb PIN o biometria local

“Sense contrasenya” descriu el viatge de l'usuari, no tots els desplegaments possibles. Un servei pot utilitzar WebAuthn com a segon factor després d'una contrasenya, com a credencial multifactor principal o juntament amb altres autenticadors. La part dependent ha de decidir quines característiques i indicadors de credencial compleixen l'assegurança de l'acció protegida.

Com funciona el registre de FIDO2

El registre, també anomenat creació de credencials, vincula una nova credencial de clau pública a un compte de la part dependent.

1. El servidor crea opcions de registre

La part dependent genera un desafiament nou i impredictible i envia opcions de creació de credencials de clau pública al client. Les opcions identifiquen la part dependent, el compte d'usuari, els algorismes acceptats, les preferències de l'autenticador, la preferència de certificació i els identificadors de credencials existents exclosos quan sigui pertinent.

Els desafiaments han de ser d'un sol ús, de curta durada, vinculats a la sessió i l'usuari correctes, i emmagatzemats o verificables pel servidor. Un desafiament generat només al navegador no pot protegir la cerimònia del servidor.

2. El client invoca WebAuthn

L'aplicació crida navigator.credentials.create() amb les opcions de clau pública. El navegador comprova l'origen i el context de seguretat, i després demana a un autenticador disponible que creï una credencial.

3. L'autenticador obté el consentiment de l'usuari

L'autenticador requereix la presència de l'usuari i, si es sol·licita i es suporta, la verificació de l'usuari. La presència de l'usuari pot ser un toc o una acció explícita. La verificació de l'usuari significa que l'autenticador verifica localment l'usuari mitjançant un PIN, un secret del dispositiu, una biometria o un altre mètode compatible.

Una biometria local normalment desbloqueja l'ús de la credencial; la plantilla biomètrica no s'envia al lloc web com a secret d'autenticació.

4. L'autenticador crea un parell de claus

L'autenticador crea un parell de claus de credencial delimitat a la part dependent. La clau privada roman protegida per l'autenticador o el seu teixit de sincronització. La credencial resultant conté la clau pública, l'identificador de la credencial, les dades de l'autenticador, les dades del client i la informació de certificació segons el format seleccionat.

5. El servidor valida i emmagatzema la credencial

La part dependent valida la cerimònia abans d'emmagatzemar res. Les comprovacions inclouen:

• desafiament esperat;
• origen esperat;
• hash de l'identificador de la part dependent correcte;
• estat esperat entre orígens i topOrigin quan la cerimònia està incrustada;
• indicadors de presència i verificació de l'usuari segons la política;
• algorisme i paràmetres de clau acceptats;
• estructura de certificació i política de confiança si es sol·licita la certificació;
• unicitat i associació amb el compte d'usuari correcte.

El servidor emmagatzema l'identificador de la credencial, la clau pública, la vinculació del compte, el comptador de signatures o l'estat aplicable, els transports o les metadades on siguin útils, i la informació del cicle de vida de la credencial. Mai necessita la clau privada.

Com funciona l'autenticació FIDO2

L'autenticació demostra el control d'una credencial prèviament registrada.

1. El servidor crea opcions de sol·licitud

La part dependent genera un nou desafiament i envia opcions d'asserció. Pot incloure una llista d'identificadors de credencials permesos o utilitzar credencials detectables perquè l'autenticador pugui identificar el compte.

2. El client sol·licita una asserció

L'aplicació crida navigator.credentials.get(). El navegador i l'autenticador seleccionen una credencial adequada i obtenen la presència d'usuari o la verificació d'usuari local necessària.

3. L'autenticador signa les dades de la cerimònia

L'autenticador signa el nou context de desafiament i les dades de l'autenticador utilitzant la clau privada de la credencial. Com que la credencial està delimitada a la part dependent, un origen de phishing no relacionat no pot demanar a l'autenticador que produeixi una asserció vàlida per al servei real.

4. El servidor verifica l'asserció

La part dependent verifica el desafiament esperat, l'origen, el hash de la part dependent, la signatura amb la clau pública emmagatzemada, els indicadors requerits, la credencial permesa, la vinculació de l'usuari i el comptador o l'estat de còpia de seguretat rellevant. Només llavors hauria de crear o elevar una sessió de l'aplicació.

Cada asserció demostra el control en un moment. La creació de sessions, la protecció de tokens, la reautenticació, l'autorització de transaccions, el tancament de sessió i la revocació segueixen sent responsabilitats separades de l'aplicació.

Per què FIDO2 és resistent al phishing

Les contrasenyes i els codis d'un sol ús es poden introduir en un lloc impostor, que els pot retransmetre al servei real. FIDO2 utilitza una credencial delimitada a la part dependent i vincula criptogràficament l'asserció al context del verificador esperat.

Els requisits d'autenticació NIST SP 800-63B-4 descriuen WebAuthn com a resistent al phishing mitjançant la vinculació del nom del verificador. La sortida de l'autenticador es vincula al nom de domini autenticat en lloc de dependre que l'usuari noti una pàgina enganyosa.

La resistència al phishing té límits:

• No atura el programari maliciós ni un atacant que ja controla una sessió autenticada.
• No impedeix que un usuari aprovi una transacció maliciosa dins del servei genuí.
• No assegura una ruta de recuperació de compte que pugui reemplaçar la credencial.
• No demostra que la persona que controla l'autenticador sigui la persona del món real que una organització volia registrar.

Resistència a la repetició i gestió de desafiaments

Una asserció enregistrada no hauria de funcionar en una cerimònia posterior perquè cada sol·licitud utilitza un nou desafiament. NIST descriu els autenticadors criptogràfics que incorporen nonces o desafiaments com a resistents a la repetició.

Els errors d'implementació poden eliminar aquesta propietat. Els errors comuns inclouen desafiaments predictibles, reutilització de desafiaments, acceptació d'un desafiament per al compte equivocat, no aplicació de la caducitat o validació només de la signatura ignorant l'origen i el context de la part dependent.

El servidor hauria de marcar un desafiament consumit atòmicament. Si les sol·licituds paral·leles competeixen, només una cerimònia exitosa hauria de poder utilitzar aquest desafiament.

Presència de l'usuari i verificació de l'usuari

WebAuthn distingeix:

• Presència de l'usuari (UP): l'usuari va realitzar una interacció que indica participació.
• Verificació de l'usuari (UV): l'autenticador va verificar localment l'usuari mitjançant un factor d'activació com un PIN o una biometria.

La presència per si sola no és una autenticació multifactor. Un servei que protegeix una acció de major risc pot requerir l'indicador UV i rebutjar asseveracions que només mostren presència. Els requisits haurien d'establir els valors dels indicadors esperats en lloc de dependre d'una etiqueta d'interfície com ara “Utilitza Face ID”.

La qualitat de la verificació local també varia segons l'autenticador. La part dependent pot tenir una visibilitat limitada de la implementació biomètrica o del PIN exacta per als autenticadors proporcionats per l'usuari, de manera que la política hauria de ser proporcional a la transacció i a la població de desplegament.

Autenticadors de plataforma, itinerants i entre dispositius

Autenticadors de plataforma

Aquests estan integrats amb un telèfon, portàtil o sistema operatiu. Poden proporcionar un viatge curt utilitzant el mètode de desbloqueig local del dispositiu. El compromís és la dependència de la recuperació del compte de la plataforma, la seguretat del dispositiu i el comportament de sincronització.

Autenticadors itinerants

Les claus de seguretat externes es poden transportar entre dispositius i connectar-se a través de transports compatibles. Són útils per a casos d'ús de la força de treball, administratius o d'alta assegurança, especialment quan la no exportabilitat de les credencials i l'emissió gestionada són importants.

Autenticació entre dispositius

Els fluxos híbrids poden utilitzar un telèfon proper per autenticar una sessió en un altre dispositiu. Els mecanismes de traspàs i proximitat milloren la usabilitat, però afegeixen detalls de la interfície d'usuari i del model d'amenaça que s'han de provar en lloc de tractar-los com a idèntics a l'autenticació del mateix dispositiu.

Admet diverses credencials per compte. Els usuaris reemplacen telèfons, perden claus de seguretat, utilitzen dispositius de treball i personals, i necessiten una manera segura de nomenar, inspeccionar i eliminar credencials.

Claus d'accés vinculades al dispositiu i sincronitzades

Una clau d'accés és una credencial FIDO dissenyada per iniciar sessió sense contrasenya. Les claus d'accés poden ser:

• Vinculades al dispositiu: la clau privada de la credencial roman lligada a un autenticador o dispositiu gestionat.
• Sincronitzades: el material de la credencial s'encripta i se sincronitza a través del teixit d'un proveïdor per utilitzar-lo en dispositius elegibles.

Les claus d'accés sincronitzades milloren la disponibilitat i la recuperació, mentre que les credencials vinculades al dispositiu poden proporcionar una no exportabilitat més forta. L'orientació de l'autenticador sincronitzable NIST SP 800-63B-4 permet autenticadors sincronitzables en contextos fins al nivell d'assegurança d'autenticació 2 quan es compleixen els seus requisits, però la sincronització entra en conflicte amb la no exportabilitat requerida al nivell 3.

No inferiu l'assegurança de la paraula “clau d'accés”. Avalueu si les credencials estan recolzades, són elegibles per a còpia de seguretat, compartides, gestionades, vinculades al dispositiu, certificades i activades amb verificació de l'usuari segons la política de la part dependent.

Certificació i confiança de l'autenticador

La certificació pot proporcionar proves sobre la procedència o les propietats d'un autenticador en el registre. No és el mateix que la signatura d'autenticació, i no identifica l'usuari humà.

Els serveis al consumidor sovint minimitzen la recopilació de certificacions per a la privadesa i la compatibilitat amb l'ecosistema. Els desplegaments de força de treball gestionada poden requerir models o certificacions d'autenticador específics. La decisió hauria de respondre a una pregunta del model d'amenaça en lloc de recopilar proves d'identificació del dispositiu per defecte.

Si s'utilitza la certificació:

• definiu els formats acceptats i els ancoratges de confiança;
• valideu correctament les rutes i les declaracions dels certificats;
• especifiqueu la gestió de l'actualització i la revocació de metadades;
• planifiqueu autenticadors sense certificació de confiança;
• documenteu les conseqüències de la privadesa i la retenció;
• proveu la substitució quan un model acceptat canvia d'estat.

FIDO2 no substitueix la prova d'identitat

FIDO2 demostra el control d'una credencial registrada a una part dependent. No estableix el nom legal, l'edat, l'adreça, l'estat regulador o la singularitat del món real de la persona que la registra.

Aquesta distinció crea tres patrons comuns:

1. Registre pseudònim: el servei necessita un compte segur però no una identitat verificada del món real.
2. Registre vinculat a la identitat: la prova d'identitat es realitza primer, i després una credencial FIDO es vincula al compte verificat.
3. Pas a pas o recuperació: el servei torna a verificar la identitat o utilitza altres proves fortes abans de permetre que es reemplaci un autenticador perdut.

La vinculació ha de ser explícita. Registreu quin compte i estat de prova existien quan es va afegir la credencial, quina sessió la va autoritzar i si un risc posterior hauria de desencadenar la reautenticació o l'actualització d'identitat.

Recuperació del compte i cicle de vida de la credencial

La recuperació és on molts desplegaments resistents al phishing es degraden. Si un usuari pot reemplaçar totes les credencials FIDO utilitzant un enllaç de correu electrònic o preguntes de suport febles, un atacant atacarà aquesta ruta en el seu lloc.

Un cicle de vida complet cobreix:

• afegir un segon autenticador;
• nom i visualització de les credencials registrades;
• pèrdua del dispositiu i sospita de compromís;
• revocació d'una credencial sense destruir el compte;
• recuperació amb codis, un altre autenticador, suport gestionat o prova d'identitat;
• notificació a l'usuari a través d'un canal independent;
• retard o limitació d'accions d'alt risc després de la recuperació;
• registre de qui va canviar el conjunt de credencials i per què;
• tancament de sessions creades abans de la notificació del compromís.

L'assegurança de recuperació ha de coincidir amb la conseqüència de reemplaçar l'autenticador. Un compte comunitari de baix risc i un administrador que pot moure fons no necessiten la mateixa ruta.

Com avaluar un desplegament de FIDO2

Validació del protocol

Proveu la generació i caducitat del desafiament, la validació exacta de l'origen, les regles d'identificació de la part dependent, la verificació de la signatura, els algorismes compatibles, la política d'UP i UV, l'associació de credencials, els comptadors, els indicadors de còpia de seguretat i la gestió d'errors. Preferiu una biblioteca de servidor mantinguda en lloc d'una anàlisi binària escrita a mà, tot i que entengueu el que valida.

Cobertura de l'autenticador

Proveu autenticadors de plataforma i itinerants en navegadors, sistemes operatius, dispositius, transports, polítiques empresarials i configuracions d'accessibilitat compatibles. Incloeu la creació de credencials, l'inici de sessió, la interfície d'usuari condicional, l'ús entre dispositius i la substitució del dispositiu.

Seguretat del compte i de la sessió

Reviseu qui pot afegir una credencial, si es requereix una autenticació recent, com s'eleven les sessions, quan es produeix la reautenticació i com afecten els canvis de credencials les sessions existents.

Recuperació i suport

Simuleu la pèrdua, els dispositius robats, el correu electrònic compromès, el canvi de SIM, la suplantació de suport i l'accés maliciós a la llar o al lloc de treball. Mesureu tant la resistència de l'atacant com la finalització de l'usuari genuí.

Privadesa i observabilitat

Minimitzeu la certificació i les dades del dispositiu al que necessita la política. Eviteu utilitzar identificadors de credencials estables entre parts dependents; l'abast de WebAuthn està dissenyat per evitar-ho. Registreu els motius i els resultats de la cerimònia sense filtrar dades sensibles del client.

Errors comuns d'implementació de FIDO2

Comprovar la signatura però no el context

Una signatura vàlida és insuficient si el servidor no verifica exactament el desafiament, l'origen, l'identificador de la part dependent, els indicadors i la vinculació del compte.

Anomenar cada clau d'accés multifactor

El servidor ha de verificar si s'ha produït la verificació de l'usuari i si les característiques de la credencial compleixen la política. La presència de l'usuari per si sola no és el mateix que la verificació local de l'usuari.

Permetre l'addició silenciosa de credencials

L'addició d'un nou autenticador canvia la seguretat del compte. Requereix una autenticació recent o una cerimònia de recuperació adequada, notifiqueu l'usuari i registreu l'esdeveniment.

Donar suport a una sola credencial

Els comptes d'una sola credencial creen una recuperació fràgil i fomenten alternatives més febles. Permeteu múltiples autenticadors amb una gestió i revocació clares.

Deixar la contrasenya com a alternativa igual

Si una contrasenya sempre pot eludir la ruta FIDO, la resistència al phishing només pot existir al botó preferit. Restringiu o elimineu rutes més febles segons el risc i l'etapa de migració.

Ignorar les sessions del servidor

FIDO2 autentica la cerimònia d'inici de sessió. Protegiu les cookies i els tokens, rotuleu les sessions després de l'autenticació, requeriu un pas a pas per a accions sensibles i revoqueu les sessions compromeses.

Una llista de verificació de desplegament

Abans del llançament, confirmeu que:

• els desafiaments són impredictibles, d'un sol ús, de curta durada i vinculats a la sessió correcta;
• l'origen, l'identificador de la part dependent, la signatura, l'algorisme, els indicadors i la propietat de la credencial estan validats;
• els requisits d'UP i UV són explícits per a cada acció protegida;
• els casos de plataforma, itinerància, sincronització, vinculació a dispositiu i entre dispositius es proven com a compatibles;
• els usuaris poden registrar diverses credencials i nomenar, inspeccionar i revocar-les de manera segura;
• l'addició i la recuperació de credencials requereixen una assegurança proporcionada i generen notificacions;
• la recopilació de certificacions té una política de confiança, privadesa i metadades definida;
• les alternatives de contrasenya, codi d'un sol ús, suport i recuperació d'identitat estan modelades per amenaces;
• les sessions autenticades i l'autorització de transaccions estan protegides per separat;
• les biblioteques de protocols, el suport del navegador, les deprecacions i els esdeveniments de seguretat tenen propietaris.

On encaixa Didit al costat de FIDO2

FIDO2 gestiona l'autenticació un cop s'ha registrat una credencial. Didit pot donar suport a la decisió d'identitat adjacent mitjançant la verificació d'identitat, la detecció de vivacitat i l'autenticació biomètrica. El preu publicat de l'autenticació biomètrica és de 0,10 $ per comprovació.

Els equips poden revisar les tarifes actuals dels mòduls a la pàgina de preus. No s'ha d'assumir que aquests productes implementin FIDO2 a partir d'aquesta descripció: el punt arquitectònic és que la prova d'identitat, les comprovacions biomètriques, l'autenticació de credencials FIDO, la recuperació del compte i l'autorització d'aplicacions són decisions de confiança diferents.

Preguntes freqüents

Què significa FIDO2?

FIDO es refereix a Fast Identity Online. FIDO2 és la família d'estàndards que combina W3C WebAuthn amb FIDO Alliance CTAP per a l'autenticació de clau pública.

FIDO2 és el mateix que WebAuthn?

No. WebAuthn defineix l'API de la part dependent i del client i el model de dades. FIDO2 inclou WebAuthn més CTAP, que connecta la plataforma client amb els autenticadors itinerants.

Les claus d'accés són credencials FIDO2?

Sí. Les claus d'accés són credencials FIDO detectables dissenyades per a l'inici de sessió sense contrasenya. Es poden sincronitzar entre dispositius elegibles o romandre vinculades al dispositiu.

És FIDO2 resistent al phishing?

L'autenticació FIDO2 correctament validada és resistent al phishing perquè la credencial està delimitada a la part dependent i l'asserció està vinculada a aquest context de verificador. Una recuperació feble o una sessió ja compromesa encara poden eludir la protecció prevista.

FIDO2 utilitza biometria?

Pot utilitzar una biometria local per activar un autenticador i establir la verificació de l'usuari. La part dependent normalment rep el resultat i l'asserció criptogràfica, no la plantilla biomètrica.

FIDO2 verifica la identitat d'una persona?

No. Verifica el control d'una credencial registrada. La prova d'identitat del món real és una decisió de registre o recuperació separada quan el servei ho requereix.

Què passa quan un usuari perd tots els autenticadors?

El servei necessita una política de recuperació proporcional al risc del compte. Les opcions poden incloure un altre autenticador registrat, codis de recuperació, recuperació administrativa gestionada o prova d'identitat renovada, amb notificació i restriccions posteriors a la recuperació.

Referències principals

• Especificacions d'autenticació d'usuari de la FIDO Alliance
• Instantània de la recomanació candidata de W3C Web Authentication Level 3
• Estàndard proposat CTAP 2.3 de la FIDO Alliance
• NIST SP 800-63B-4: Gestió d'autenticació i autenticadors
• Requisits d'autenticació NIST SP 800-63B-4

FIDO2 substitueix els secrets del verificador reutilitzables per credencials de clau pública delimitades i noves cerimònies criptogràfiques. El seu valor només sobreviu quan la part dependent valida el context complet, gestiona el cicle de vida de la credencial, protegeix les sessions i les accions sensibles, i dedica la mateixa atenció de seguretat a la recuperació que a l'inici de sessió.