Passkey accanto alle password, senza confondere nessuno
Come EAuth offre passkey e password sulla stessa pagina di accesso, perché la password resta e da cosa protegge una passkey che una password non può fermare.
Ogni applicazione che usa EAuth per l'accesso offre le passkey accanto alla password, sulla stessa pagina. Nessuno deve cambiare abitudini, a nessuno serve una spiegazione su cos'è una passkey prima di poterla usare, e la password non sparisce. Questo articolo parla di come convivono le due, perché è lì che falliscono quasi tutte le introduzioni delle passkey.
Cos'è una passkey, in un paragrafo
Una passkey è una coppia di chiavi. La metà privata resta sul telefono, sul portatile o sulla chiave di sicurezza della persona, protetta dal blocco del dispositivo stesso: impronta digitale, volto o PIN. La metà pubblica viene registrata presso il sito. Accedere significa che il sito invia una challenge e il dispositivo la firma, dopo che la persona lo ha sbloccato. Il sito non vede mai un segreto, quindi dal nostro database non c'è nulla che possa trapelare, e il browser lega la passkey a eauth.me, quindi una copia della pagina di accesso su un altro dominio non ottiene nulla che quella vera accetti. Quest'ultima proprietà è quella che una password non può avere: chi digita la propria password in una copia convincente della pagina l'ha regalata; una passkey lì si rifiuta di funzionare.
Una pagina, due ingressi
La pagina di accesso di EAuth mostra i campi per e-mail e password e, sotto, «Sign in with a passkey». Tutta l'interfaccia è questa. Il pulsante compare solo dopo che lo script della pagina ha verificato che il browser può usare una passkey, quindi un browser che non può farlo non mostra mai un pulsante che non fa nulla.
Dietro, la pagina chiede al browser la conditional mediation. Il campo e-mail è marcato username webauthn, e un browser che possiede una passkey per eauth.me la propone tra i suggerimenti di quel campo, come propone una password salvata. Un browser che non ne ha non mostra nulla in più. Nessuno digita prima un indirizzo: è la passkey scelta dalla persona a indicare l'account. Chi ha una passkey la usa con un tocco; chi non ce l'ha vede una normale pagina di accesso.
Non c'è una modalità «passwordless» separata da attivare, né una richiesta a ogni visita che Le chiede se vuole configurarne una. Una richiesta del genere abitua le persone a chiudere le finestre di dialogo senza leggerle, che è il contrario di ciò di cui ha bisogno la sicurezza.
Dove nasce una passkey
Nella pagina dell'account, sotto Security, accanto al secondo fattore. Per aggiungerne una viene chiesta prima la password. Una passkey è un ingresso che sopravvive a un cambio di password, quindi un browser rimasto connesso non deve bastare a qualcuno per lasciarne una, e le password sbagliate lì vengono contate: cinque per account in quindici minuti. Poi il dispositivo crea la chiave. La persona può darle un nome, «MacBook» o «iPhone», così l'elenco significa qualcosa anche un anno dopo; senza nome, prende quello del browser e della piattaforma. Ogni aggiunta viene comunicata per e-mail all'indirizzo dell'account, con le istruzioni su cosa fare se non è stata la persona stessa.
Per rimuoverne una bastano un pulsante e una conferma. Non c'è un minimo: una persona può rimuovere la sua ultima passkey, perché ha ancora la password.
Le passkey create su un telefono o su un portatile di solito vengono sincronizzate dalla piattaforma, quella di Apple o di Google, sugli altri dispositivi della persona. EAuth registra se una passkey è sincronizzata e lo indica nella pagina dell'account, perché cambia cosa significa perdere un dispositivo: una passkey sincronizzata sopravvive, una passkey su una chiave hardware no. L'esportazione dei dati di una persona che un'applicazione produce per una richiesta GDPR riporta la stessa indicazione.
Una chiave hardware tiene anche un contatore che sale a ogni uso. Quando non sale, la chiave potrebbe essere stata copiata, ed EAuth non si limita a rifiutare quell'accesso: rimuove la passkey, perché una copia continuerebbe a funzionare, e dice alla persona di accedere con la password e di aggiungerne una nuova. Le passkey sincronizzate non tengono un contatore e non vengono trattate come copie.
Perché la password resta
Due motivi, e nessuno dei due è nostalgia.
I dispositivi di una persona cambiano. Un telefono nuovo su cui l'account della piattaforma non è ancora attivo, un portatile prestato, un computer aziendale con un browser blindato: ognuno di questi è un momento in cui la passkey non è a portata di mano. La password è l'ingresso, e il secondo fattore vale anche per lei.
Il recupero deve esistere. Con la password mantenuta, perdere una passkey non fa perdere nulla: l'account ha ancora la sua password, e una password dimenticata si reimposta con un link all'indirizzo confermato, come prima. Se la password sparisse, il recupero dovrebbe poggiare solo su quel link, che è più debole di entrambe. Mantenerla significa che la passkey è un passo avanti, non un passo di lato.
Cosa non fa
Una passkey non è un secondo fattore per la password. Una passkey il cui dispositivo ha verificato la persona, con un PIN, un'impronta o il volto, è completa da sola: qualcosa che si possiede e qualcosa che si sa o che si è. Una passkey che ha registrato solo un tocco, come fanno alcune chiavi di sicurezza, conta come un solo fattore, e a un account che ha attivato un secondo fattore viene chiesto il codice, come dopo una password. L'accesso con la password chiede comunque il codice, se la persona ne ha configurato uno. Le due sono strade separate.
Una passkey non sostituisce nemmeno i limiti sul modulo della password. Un attaccante che ignora la passkey e tira a indovinare le password incontra gli stessi limiti di prima: venti password sbagliate per account in quindici minuti da qualunque provenienza, cinque da un singolo indirizzo, contate prima che la password venga verificata. Le richieste con passkey condividono il limite per indirizzo di trenta richieste di accesso al minuto, quindi una passkey accanto al modulo non allarga nulla.
Per gli sviluppatori
Nella Sua integrazione non cambia nulla: nessuna impostazione, nessuna chiamata all'SDK. Un utente che accede con una passkey riceve lo stesso codice di autorizzazione e lo stesso ID token di uno che ha usato la password. Il token non dice quale dei due è stato usato, quindi oggi Lei non può trattare diversamente gli accessi con passkey. È un limite, e preferisco dichiararlo piuttosto che lasciarLa cercare un claim che non c'è.
Un account su EAuth appartiene a una sola applicazione. Una persona che usa due applicazioni ha due account e aggiunge una passkey a ciascuno. Siccome ogni passkey appartiene a eauth.me, il browser può proporle entrambe su ciascuna pagina di accesso; quella dell'altra applicazione viene rifiutata con un messaggio che lo spiega, e non si accede a nulla. La nostra console per sviluppatori e la dashboard usano la stessa pagina di accesso, quindi anche lì gli sviluppatori hanno le passkey.
Fonti
- Web Authentication: An API for accessing Public Key Credentials, Level 3, W3C, consultato il
- Bootstrapping, passkeys.dev, consultato il
- Multifactor Authentication Cheat Sheet, OWASP, consultato il
Scritto da Samuel Krauss, Founder. Archiviato in eauth, passkeys, security, webauthn.
Tradotto dall’inglese. Leggi l’originale inglese