Verifica prontezza Passkey — Testa WebAuthn

Le passkey sostituiscono molti flussi con password con credenziali protette dal tuo dispositivo. Questa guida spiega esattamente cosa testa questo checker, come testare il telefono o il computer che hai in mano, cosa significano i risultati WebAuthn e perché questo strumento non chiede mai i dettagli dei tuoi account.

What does this tool test?

Questo strumento testa il dispositivo e il browser che stai usando ora. Apri la pagina sul telefono, tablet o computer che vuoi valutare, poi premi il pulsante di test sicuro. Verifica se la pagina corrente è un contesto sicuro, se il browser espone l’API PublicKeyCredential, se è disponibile un autenticatore di piattaforma e se è supportata la conditional mediation. Non testa un altro telefono da remoto e non ispeziona i tuoi account.

What is a passkey?

Una passkey è una credenziale WebAuthn che permette a un servizio di autenticarti usando un metodo di sblocco del dispositivo come Face ID, Touch ID, i biometrics Android, Windows Hello o un PIN del dispositivo. La chiave privata resta protetta dal fornitore della credenziale; il sito riceve una chiave pubblica e una risposta firmata durante il login. Questo design può resistere a molti attacchi di phishing e riutilizzo delle password, ma la qualità dell’esperienza di login dipende comunque dall’implementazione del servizio e dalle scelte di recovery dell’account.

What does Supported mean?

Supported significa che il browser ha esposto l’API di capacità rilevante o ha riportato un risultato positivo. È un forte indicatore che il dispositivo potrebbe partecipare ai flussi con passkey. Non è però una promessa che ogni sito funzionerà: il sito deve usare HTTPS, implementare correttamente WebAuthn, creare una challenge, verificare la risposta sul suo server e gestire la registrazione dell’account. Anche le impostazioni del browser, le policy aziendali e il blocco schermo del dispositivo possono influire sull’esperienza finale.

What does Unavailable mean?

Unavailable può significare che il browser non dispone dell’API, che la pagina non è sicura, che il dispositivo non ha un autenticatore di piattaforma idoneo, che un controllo di permessi è fallito o che il browser non espone la capacità opzionale. Prova la stessa pagina in un browser aggiornato su HTTPS, assicurati che sia configurato un blocco schermo o un metodo biometrico e riprova. Un risultato negativo qui non significa che l’account sia rotto; descrive soltanto questo browser e dispositivo in questo momento.

Why is there no email or password field?

Il checker è intenzionalmente senza account. Misura le capacità del browser e del dispositivo senza creare una credenziale, effettuare il login a un account o trasmettere informazioni personali. Una vera registrazione con passkey richiede che un relying party server emetta una challenge e memorizzi la credenziale pubblica. Chiedere un’email qui non renderebbe il test di capacità più accurato e introdurrebbe raccolta inutile di dati personali.

How to test different devices

Per testare un iPhone, apri lo strumento in Safari su quell’iPhone. Per Android, aprilo in Chrome o in un altro browser supportato sul telefono Android. Per testare Windows Hello, apri lo strumento sul computer Windows e conferma che Windows Hello sia configurato. Per testare un Mac, usa un browser aggiornato e il Touch ID del Mac o le impostazioni di sicurezza del dispositivo. Premi sempre il pulsante sul dispositivo che vuoi misurare.

Privacy and limitations

Il checker legge solo le API di capacità del browser. Non crea, memorizza né trasmette mai una passkey. I risultati possono cambiare dopo aggiornamenti del browser, modifiche alle policy del dispositivo, cambi nel blocco schermo o quando la pagina è servita senza HTTPS. Per l’implementazione in produzione, gli sviluppatori devono testare registrazione, autenticazione, recovery, sincronizzazione e flussi cross-device con un vero server WebAuthn.

What developers must implement on the server

Un controllo delle capacità del browser è solo il primo passo per il rollout di passkey. Un relying party deve generare una challenge fresca, inviarla al browser, verificare l’asserzione restituita sul server e legare la credenziale all’account corretto. Registrazione e autenticazione richiedono identificatori chiari di origin e relying party, politiche di user verification, protezione contro il replay e una gestione sicura degli errori. Il server dovrebbe memorizzare l’credential ID, la chiave pubblica, il counter e i metadati utente rilevanti — non la chiave privata.

Strumenti Pratix correlati