Gå til indhold
atlas

Passkey

Også kendt som: FIDO-nøgle

Et login uden adgangskode, hvor din enhed beviser, hvem du er, med en hemmelig nøgle, der aldrig forlader den.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

En loginoplysning bygget på asymmetrisk kryptografi efter FIDO-standarderne, hvor enheden har en privat nøgle for hvert website og signerer en ny udfordring med den, når brugeren låser op med fingeraftryk, ansigt eller PIN; websitet gemmer kun den offentlige nøgle.

Forklaret enkelt

Som en nøgle, der aldrig forlader dit nøglebundt og kun passer i din egen hoveddør - der er ingen kode at sige højt, så en falsk dør får intet ud af dig.

I praksis

En sagsbehandler i en region åbner medarbejderportalen på sin arbejdscomputer og rører fingeraftrykslæseren, da hun bliver bedt om at bruge sin passkey; hun er inde uden at taste noget, og en falsk side har intet at opsnappe.

Hvorfor det betyder noget

Adgangskoder bliver gættet, genbrugt og tastet ind på falske sider; en passkey virker kun på det rigtige website, og serveren gemmer ingen fælles hemmelighed, der er værd at stjæle.

Teknisk uddybning

En passkey er en FIDO2-loginoplysning, dvs. W3C Web Authentication (WebAuthn) mellem relying partyen og browseren plus FIDO Alliances Client to Authenticator Protocol (CTAP 2) mellem browseren og en ekstern autentifikator. Teknisk er det en discoverable credential, tidligere kaldt resident key: Autentifikatoren gemmer den private nøgle sammen med RP ID og et bruger-handle, så login kan starte uden brugernavn, typisk via autofill-lignende conditional mediation. WebAuthn Level 2 blev W3C Recommendation i april 2021, og Level 3 fulgte den 25. august 2026.

Ved registreringen kalder websitet navigator.credentials.create() med en tilfældig udfordring (challenge), sit RP ID (et registrerbart domæne som example.dk), et bruger-id og de accepterede algoritmer som COSE-identifikatorer, typisk -7 (ES256) og -257 (RS256), og beder om residentKey "required" og en præference for brugerverifikation. Autentifikatoren genererer et nyt nøglepar afgrænset til det RP ID og returnerer authenticator data med SHA-256-hashen af RP ID, en flag-byte, en signaturtæller, credential-id'et og den offentlige nøgle, eventuelt med en attestation. Ved login beder navigator.credentials.get() autentifikatoren signere authenticator data sammensat med hashen af clientDataJSON, som browseren udfylder med typen, udfordringen og den faktiske origin. Serveren verificerer signaturen med den gemte offentlige nøgle og kontrollerer udfordring, origin, RP ID-hash og flagene UP (bruger til stede) og UV (bruger verificeret).

Phishing-resistensen kommer af den binding: Det er browseren og ikke brugeren, der angiver origin, og autentifikatoren tilbyder slet ikke en loginoplysning, hvis RP ID ikke passer til websitet, så et forvekslingsdomæne får intet at videresende. Det er binding til verifierens navn i betydningen fra NIST SP 800-63B-4 §3.2.5. På serversiden gemmes kun offentlige nøgler, så et databasebrud giver intet, der kan bruges til login.

Passkeys er enten synkroniserede eller enhedsbundne. Efter Apples, Googles og Microsofts fælles tilsagn i maj 2022 begyndte platformene at synkronisere passkeys via iCloud-nøglering, Google Password Manager og tredjeparts adgangskodeadministratorer; flagene BE (backup eligible) og BS (backup state) afslører det, og synkroniserede autentifikatorer returnerer ofte signaturtælleren nul, så tællerbaseret kloningsdetektion bliver meningsløs. SP 800-63B-4 accepterer synkroniserbare autentifikatorer op til AAL2, men ikke på AAL3, som kræver en nøgle, der ikke kan eksporteres; administratorer og brug med højt sikringsniveau kræver derfor enhedsbundne passkeys på sikkerhedsnøgler eller platform-TPM'er, ofte med attestation, så modellen kan verificeres. Login på tværs af enheder bruger hybrid-transporten, en QR-kode plus et Bluetooth-nærhedstjek, så en telefon kan autentificere en bærbar. De tilbageværende risici er den svageste tilbageværende gendannelses- eller reservemetode (SMS eller adgangskode, der stadig er slået til), kompromittering af synkroniseringskontoen og tyveri af den sessionscookie, der udstedes efter et fuldt phishing-resistent login.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Kryptografisk nøgle
  2. →Digital identitet
  3. →Loginoplysning (credential)
  4. →Asymmetrisk kryptografi (public key)
  5. →Autentificering
  6. →Passkey

Relationer

Forveksl ikke med
Engangskode (OTP)
Alternativ til
Adgangskode

Kilder og videre læsning

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.