Passkey: cosa diavolo e perché?

Ripubblicato da Platone

Seguaci: 0

Queste cose chiamate chiavi di accesso sicuramente stanno facendo il giro in questi giorni. Erano un'attrazione principale a W3C TPAC 2022, ha ottenuto il supporto in Safari 16, stanno trovando la loro strada macOS e iOS, e dovrebbero esserlo il futuro per i gestori di password come 1Password. Loro sono già supportato in Android e presto troveranno la loro strada in Chrome OS e Windows nelle versioni future.

I miglioramenti della sicurezza del sistema operativo Geeky non fanno esattamente grandi titoli nella comunità front-end, ma è ovvio che le passkey diventeranno una "cosa". E considerando come le password e le app per password influenzano l'esperienza utente di cose come l'autenticazione e l'elaborazione dei moduli, potremmo almeno pensare a loro, quindi sappiamo cosa sta arrivando.

Questo è il punto di questo articolo. Ho studiato e sperimentato le passkey e l'API WebAuthn su cui sono costruite da un po 'di tempo. Permettetemi di condividere ciò che ho imparato.

Sommario

Terminologia

Ecco la sezione obbligatoria della terminologia che vorrai conoscere mentre scaviamo. Come la maggior parte della tecnologia, le passkey sono realizzate con verbosità esoterica e acronimi che sono spesso ostacoli alla comprensione. Proverò a demistificare diversi per te qui.

Festa di affidamento: il server su cui ti autenticherai. Useremo "server" per indicare il Relying Party in questo articolo.
Cliente: nel nostro caso, il browser web o il sistema operativo.
Autenticatore: Dispositivi software e/o hardware che consentono la generazione e l'archiviazione di coppie di chiavi pubbliche.
FIDO: un organismo di standard aperti che crea anche specifiche relative alle credenziali FIDO.
WebAuthn: il protocollo sottostante per le passkey, noto anche come a FIDO2 credenziale o credenziali FIDO per dispositivo singolo.
chiavi di accesso: WebAuthn, ma con sincronizzazione cloud (chiamate anche credenziali FIDO multi-dispositivo, credenziali rilevabili o credenziali residenti).
Crittografia a chiave pubblica: Una coppia di chiavi generata che include una chiave privata e una pubblica. A seconda dell'algoritmo, dovrebbe essere utilizzato per la firma e la verifica o per la crittografia e la decrittografia. Questo è anche noto come crittografia asimmetrica.
RSA: Un acronimo dei nomi dei creatori, Rivest Shamir e Adel. RSA è una famiglia di crittografia a chiave pubblica più vecchia, ma ancora utile, basata su numeri primi di fattorizzazione.
Crittografia a curva ellittica (ECC): Una nuova famiglia di crittografia basato su curve ellittiche.
ES256: Una chiave pubblica a curva ellittica che utilizza un algoritmo di firma ECDSA (PDF) Con SHA256 per l'hashing.
RS256: Come ES256, ma utilizza RSA con RSASSA-PKCS1-v1.5 e SHA256.

Cosa sono le chiavi di accesso?

Prima di poter parlare nello specifico delle passkey, dobbiamo parlare di un altro protocollo chiamato WebAuthn (noto anche come FIDO2). Le passkey sono una specifica basata su WebAuthn. WebAuthn consente la crittografia a chiave pubblica per sostituire le password. Utilizziamo una sorta di dispositivo di sicurezza, come una chiave hardware o Trusted Platform Module (TPM), per creare chiavi private e pubbliche.

La chiave pubblica è utilizzabile da chiunque. La chiave privata, invece, non può essere rimossa dal dispositivo che l'ha generata. Questo era uno dei problemi con WebAuthn; se perdi il dispositivo, perdi l'accesso.

Passkeys risolve questo problema fornendo una sincronizzazione cloud delle tue credenziali. In altre parole, ciò che generi sul tuo computer ora può essere utilizzato anche sul tuo telefono (anche se in modo confuso, ci sono anche credenziali per singolo dispositivo).

Attualmente, al momento in cui scriviamo, solo iOS, macOS e Android forniscono il supporto completo per le passkey sincronizzate con il cloud e, anche in questo caso, sono limitate dal browser utilizzato. Google e Apple forniscono un'interfaccia per la sincronizzazione tramite i loro Gestore password di Google ed Portachiavi iCloud di Apple servizi, rispettivamente.

In che modo le passkey sostituiscono le password?

Nella crittografia a chiave pubblica, puoi eseguire ciò che è noto come firma. La firma prende un pezzo di dati e poi lo esegue attraverso un algoritmo di firma con la chiave privata, dove può quindi essere verificato con la chiave pubblica.

Chiunque può generare una coppia di chiavi pubbliche e non è attribuibile a nessuna persona poiché chiunque potrebbe averla generata in primo luogo. Ciò che lo rende utile è che solo i dati firmati con la chiave privata possono essere verificati con la chiave pubblica. Questa è la parte che sostituisce una password: un server memorizza la chiave pubblica e noi accediamo verificando di avere l'altra metà (ad esempio la chiave privata), firmando una sfida casuale.

Come ulteriore vantaggio, dal momento che stiamo archiviando le chiavi pubbliche dell'utente all'interno di un database, non ci sono più preoccupazioni per le violazioni delle password che interessano milioni di utenti. Ciò riduce il phishing, le violazioni e una serie di altri problemi di sicurezza che il nostro mondo dipendente dalle password deve affrontare attualmente. Se un database viene violato, tutto ciò viene archiviato nelle chiavi pubbliche dell'utente, rendendolo praticamente inutile per un utente malintenzionato.

Niente più e-mail dimenticate e le relative password! Il browser ricorderà quali credenziali hai utilizzato per quale sito Web: tutto ciò che devi fare è fare un paio di clic e sei loggato. Puoi fornire un mezzo di verifica secondario per utilizzare la passkey, come la biometria o un pin , ma sono ancora molto più veloci delle password del passato.

Maggiori informazioni sulla crittografia

La crittografia a chiave pubblica comporta la presenza di una chiave privata e una pubblica (nota come coppia di chiavi). Le chiavi vengono generate insieme e hanno usi separati. Ad esempio, la chiave privata deve essere tenuta segreta e la chiave pubblica è destinata a chiunque desideri scambiare messaggi.

Quando si tratta di crittografare e decrittografare un messaggio, la chiave pubblica del destinatario viene utilizzata per crittografare un messaggio in modo che solo la chiave privata del destinatario possa decrittografare il messaggio. Nel linguaggio della sicurezza, questo è noto come "fornire riservatezza". Tuttavia, ciò non fornisce la prova che il mittente sia chi dice di essere, poiché chiunque può potenzialmente utilizzare una chiave pubblica per inviare a qualcuno un messaggio crittografato.

Ci sono casi in cui dobbiamo verificare che un messaggio provenga davvero dal suo mittente. In questi casi, utilizziamo la firma e la verifica della firma per assicurarci che il mittente sia chi dice di essere (noto anche come autenticità). In chiave pubblica (chiamata anche asimmetrico), questo viene generalmente fatto firmando l'hash di un messaggio, in modo che solo la chiave pubblica possa verificarlo correttamente. L'hash e la chiave privata del mittente producono una firma dopo averla eseguita attraverso un algoritmo, quindi chiunque può verificare che il messaggio provenga dal mittente con la chiave pubblica del mittente.

Come accediamo alle passkey?

Per accedere alle passkey, dobbiamo prima generarle e memorizzarle da qualche parte. Alcune di queste funzionalità possono essere fornite con un autenticatore. UN autenticatore è qualsiasi dispositivo supportato da hardware o software che fornisce la capacità di generazione di chiavi crittografiche. Pensa a quelle password monouso da cui ricevi Google Authenticator, 1Password, o LastPass.

Ad esempio, un autenticatore software può utilizzare il Trusted Platform Module (TPM) o l'enclave sicura di un dispositivo per creare le credenziali. Le credenziali possono quindi essere archiviate in remoto e sincronizzate tra dispositivi, ad esempio passkey. Un autenticatore hardware sarebbe qualcosa di simile a YubiKey, che può generare e memorizzare chiavi sul dispositivo stesso.

Per accedere all'autenticatore, il browser deve avere accesso all'hardware e per questo abbiamo bisogno di un'interfaccia. L'interfaccia che usiamo qui è il Client to Authenticator Protocol (CTAP). Consente l'accesso a diversi autenticatori su diversi meccanismi. Ad esempio, possiamo accedere a un autenticatore tramite NFC, USB e Bluetooth utilizzando CTAP.

Uno dei modi più interessanti per utilizzare le passkey è connettere il telefono tramite Bluetooth a un altro dispositivo che potrebbe non supportare le passkey. Quando i dispositivi sono accoppiati tramite Bluetooth, posso accedere al browser sul mio computer utilizzando il mio telefono come intermediario!

La differenza tra passkey e WebAuthn

Le passkey e le chiavi WebAuthn differiscono in diversi modi. Innanzitutto, le passkey sono considerate credenziali multi-dispositivo e possono essere sincronizzate su più dispositivi. Al contrario, le chiavi WebAuthn sono credenziali per singolo dispositivo, un modo elegante per dire che sei vincolato a un dispositivo per la verifica.

In secondo luogo, per autenticarsi su un server, le chiavi WebAuthn devono fornire l'handle utente per l'accesso, dopodiché un allowCredentials list viene restituito al client dal server, che informa quali credenziali possono essere utilizzate per accedere. Le passkey saltano questo passaggio e utilizzano il nome di dominio del server per mostrare quali chiavi sono già associate a quel sito. Puoi selezionare la passkey associata a quel server, poiché è già nota al tuo sistema.

Altrimenti, le chiavi sono crittograficamente le stesse; differiscono solo nel modo in cui vengono archiviati e quali informazioni utilizzano per avviare il processo di accesso.

Il processo... in poche parole

Il processo per generare un WebAuthn o una passkey è molto simile: ricevi una sfida dal server e poi usa il file navigator.credentials.create API web per generare una coppia di chiavi pubbliche. Quindi, invia la sfida e la chiave pubblica al server per essere archiviata.

Dopo aver ricevuto la chiave pubblica e la sfida, il server convalida la sfida e la sessione da cui è stata creata. In caso di verifica, la chiave pubblica viene archiviata, insieme a qualsiasi altra informazione rilevante come l'identificatore dell'utente o i dati di attestazione, nel database.

L'utente ha ancora un passaggio: recuperare un'altra sfida dal server e utilizzare il file navigator.credentials.get API per firmare la sfida. Inviamo la sfida firmata al server e il server verifica la sfida, quindi ci accede se la firma viene accettata.

C'è, ovviamente, molto di più in ogni passaggio. Ma in genere è così che accediamo a un sito Web utilizzando WebAuthn o passkey.

La carne e le patate

Le passkey vengono utilizzate in due fasi distinte: il attestazione ed asserzione fasi.

La fase di attestazione può anche essere pensata come la fase di registrazione. Ti registri con un'e-mail e una password per un nuovo sito Web, tuttavia, in questo caso, utilizzeremo la nostra passkey.

La fase di asserzione è simile a come accedi a un sito Web dopo la registrazione.

attestazione

Passkey: cosa diavolo e perché? Intelligenza dei dati PlatoBlockchain. Ricerca verticale. Ai. — Vedi a grandezza intera

Il navigator.credentials.create L'API è al centro della nostra fase di attestazione. Siamo registrati come nuovo utente nel sistema e dobbiamo generare una nuova coppia di chiavi pubbliche. Tuttavia, dobbiamo specificare quale tipo di coppia di chiavi vogliamo generare. Ciò significa che dobbiamo fornire opzioni a navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = { challenge: safeEncode(challenge), rp: { id: window.location.host, name: document.title, }, user: { id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random? name: 'Your username', displayName: 'Display name in browser', }, pubKeyCredParams: [ { type: 'public-key', alg: -7, // ES256 }, { type: 'public-key', alg: -256, // RS256 }, ], authenticatorSelection: { userVerification: 'preferred', // Do you want to use biometrics or a pin? residentKey: 'required', // Create a resident key e.g. passkey }, attestation: 'indirect', // indirect, direct, or none timeout: 60_000,
};

const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({ publicKey
});
const { id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

Otterremo PublicKeyCredential che contiene an AuthenticatorAttestationResponse che ritorna dopo la creazione. La credenziale ha l'ID della coppia di chiavi generata.

La risposta fornisce un paio di informazioni utili. Innanzitutto, abbiamo la nostra chiave pubblica in questa risposta e dobbiamo inviarla al server per essere archiviata. In secondo luogo, recuperiamo anche il file clientDataJSON proprietà che possiamo decodificare e da lì recuperare il file type, challengee origin della chiave di accesso.

Per l'attestazione, vogliamo convalidare il file type, challengee origin sul server, oltre a memorizzare la chiave pubblica con il suo identificatore, ad esempio kid. Possiamo anche facoltativamente memorizzare il file attestationObject se lo desideriamo. Un'altra proprietà utile da memorizzare è la COSE algoritmo, che è definito sopra nel nostro PublicKeyCredentialCreationOptions con alg: -7 or alg: -256, al fine di verificare agevolmente eventuali contestazioni sottoscritte in fase di asserimento.

Affermazione

Il navigator.credentials.get L'API sarà al centro della fase di asserzione. Concettualmente, questo sarebbe il punto in cui l'utente accede all'applicazione web dopo essersi registrato.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = { challenge: new TextEncoder().encode(challenge), rpId: window.location.host, timeout: 60_000,
};

const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({ publicKey, mediation: 'optional',
});
const { id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

Otterremo di nuovo un PublicKeyCredential con AuthenticatorAssertionResponse questa volta. La credenziale include nuovamente l'identificatore della chiave.

Otteniamo anche il type, challengee origin dal clientDataJSON ancora. Il signature è ora incluso nella risposta, così come il authenticatorData. Avremo bisogno di quelli e di clientDataJSON per verificare che questo sia stato firmato con la chiave privata.

Il authenticatorData include alcune proprietà che vale la pena tenere traccia Il primo è l'hash SHA256 dell'origine che stai utilizzando, situato all'interno dei primi 32 byte, utile per verificare che la richiesta provenga dallo stesso server di origine. Il secondo è il signCount, che va dal byte 33 al 37. Viene generato dall'autenticatore e deve essere confrontato con il suo valore precedente per garantire che non stia accadendo nulla di strano con la chiave. Il valore dovrebbe essere sempre 0 quando si tratta di una passkey per più dispositivi e dovrebbe essere più grande in modo casuale del precedente signCount quando si tratta di una passkey per un singolo dispositivo.

Una volta confermato il tuo login, dovresti aver effettuato l'accesso — complimenti! Passkeys è un protocollo piuttosto eccezionale, ma presenta alcuni avvertimenti.

Alcuni aspetti negativi

Ci sono molti vantaggi in Passkeys, tuttavia, ci sono alcuni problemi al momento della stesura di questo articolo. Per prima cosa, le passkey sono in qualche modo ancora all'inizio per quanto riguarda il supporto, con solo credenziali per singolo dispositivo consentite su Windows e pochissimo supporto per i sistemi Linux. Passkeys.dev fornisce un bel tavolo che è un po' come il Caniuse di questo protocollo.

Inoltre, le piattaforme passkey di Google e Apple non comunicano tra loro. Se vuoi trasferire le tue credenziali dal tuo telefono Android al tuo iPhone... beh, per ora sei sfortunato. Questo non vuol dire che non c'è interoperabilità! Puoi accedere al tuo computer utilizzando il telefono come autenticatore. Ma sarebbe molto più pulito solo averlo integrato nel sistema operativo e sincronizzato senza che fosse bloccato a livello di fornitore.

Dove stanno andando le cose?

Come sarà il protocollo passkey del futuro? Sembra abbastanza buono! Una volta ottenuto il supporto da più sistemi operativi, dovrebbe esserci un aumento dell'utilizzo e inizierai a vederlo utilizzato sempre di più in natura. Alcuni gestori di password li supporteranno anche in prima persona.

Le passkey non sono affatto supportate solo sul web. Android ed iOS entrambi supporteranno passkey nativi come cittadini di prima classe. Siamo ancora agli inizi di tutto questo, ma ci aspettiamo di vederlo menzionato sempre di più.

Dopotutto, eliminiamo la necessità di password e, così facendo, rendiamo il mondo più sicuro!