Passkey-beredskapstest — Test WebAuthn

Passkeys erstatter mange passordflyter med credentials som er beskyttet av enheten din. Denne guiden forklarer nøyaktig hva denne sjekken tester, hvordan du tester telefonen eller datamaskinen du har i hånden, hva WebAuthn-resultater betyr, og hvorfor dette verktøyet aldri ber om kontodetaljene dine.

What does this tool test?

Dette verktøyet tester enheten og nettleseren du bruker nå. Åpne siden på telefonen, nettbrettet eller datamaskinen du vil evaluere, og trykk deretter på den sikre støtte-testknappen. Den sjekker om den nåværende siden er en sikker kontekst, om nettleseren eksponerer PublicKeyCredential API, om en plattformautentikator er tilgjengelig og om betinget mediering (conditional mediation) støttes. Den tester ikke en annen telefon eksternt og den inspiserer ikke kontoene dine.

What is a passkey?

En passkey er en WebAuthn-credential som lar en tjeneste autentisere deg med en enhetsopplåsingsmetode som Face ID, Touch ID, Android biometrics, Windows Hello eller en enhets-PIN. Den private nøkkelen forblir beskyttet av credential-leverandøren; nettstedet mottar en offentlig nøkkel og et signert svar under innlogging. Dette designet kan motstå mange phishing- og gjenbruk-av-passord-angrep, men kvaliteten på den samlede innloggingsopplevelsen avhenger fortsatt av tjenestens implementasjon og valg for kontogjenoppretting.

What does Supported mean?

Supported betyr at nettleseren eksponerte den relevante capability-API-en eller rapporterte et positivt resultat. Det er en sterk indikasjon på at enheten kan delta i passkey-flyter. Det er ikke et løfte om at hvert nettsted vil fungere: nettstedet må bruke HTTPS, implementere WebAuthn riktig, opprette en challenge, verifisere svaret på serveren og håndtere registrering av konto. Nettleserinnstillinger, bedriftsregler og enhetens skjermlås kan også påvirke sluttopplevelsen.

What does Unavailable mean?

Unavailable kan bety at nettleseren mangler API-en, siden ikke er sikker, enheten ikke har en aktuell plattformautentikator, en tillatelsessjekk mislyktes eller nettleseren ikke eksponerer den valgfrie muligheten. Prøv samme side i en oppdatert nettleser over HTTPS, sørg for at skjermlås eller biometrisk metode er konfigurert, og test igjen. Et negativt resultat her betyr ikke at kontoen er ødelagt; det beskriver bare denne nettleseren og enheten i dette øyeblikket.

Why is there no email or password field?

Sjekkeren er bevisst uten konto. Den måler nettleser- og enhetskapabilitet uten å opprette en credential, logge inn på en konto eller overføre personlig informasjon. En ekte passkey-registrering krever at en relying party-server utsteder en challenge og lagrer den offentlige credentialen. Å be om en e-postadresse her ville ikke gjort kapabilitetstesten mer nøyaktig og ville introdusert unødvendig innsamling av personopplysninger.

How to test different devices

For å teste en iPhone, åpne verktøyet i Safari på den iPhonen. For å teste Android, åpne det i Chrome eller en annen støttet nettleser på Android-telefonen. For å teste Windows Hello, åpne verktøyet på Windows-maskinen og bekreft at Windows Hello er konfigurert. For å teste en Mac, bruk en moderne nettleser og Macens Touch ID eller sikkerhetsinnstillinger for enheten. Trykk alltid på knappen på enheten du ønsker å måle.

Privacy and limitations

Sjekkeren leser kun nettleserens capability-API-er. Den oppretter aldri, lagrer eller overfører en passkey. Resultater kan endre seg etter nettleseroppdateringer, endringer i enhetspolicy, skjermlåsendringer eller når siden serveres uten HTTPS. For produksjonsimplementasjon må utviklere teste registrering, autentisering, gjenoppretting, synkronisering og kryss-enhet-flyter med en ekte WebAuthn-server.

What developers must implement on the server

En nettleser-kapabilitetssjekk er bare første steg i en reell passkey-rulling. En relying party må generere en fersk challenge, sende den til nettleseren, verifisere den returnerte påstanden på serveren og knytte credential til riktig konto. Registrering og autentisering trenger klare origin- og relying-party-identifikatorer, policy for brukerverifisering, replay-beskyttelse og sikker feilhåndtering. Serveren bør lagre credential ID, offentlig nøkkel, counter og relevant brukermetadata — ikke den private nøkkelen.

Relaterte Pratix-verktøy