Adgangsnøkler: Hva pokker og hvorfor?

Disse tingene kalt adgangsnøkler gjør sikkert rundene i disse dager. De var en hovedattraksjon kl W3C TPAC 2022, fikk støtte i Safari 16, finner veien inn macOS og iOS, og er beregnet til å være fremtiden for passordbehandlere som 1Password. De er allerede støttet i Android, og vil snart finne veien til Chrome OS og Windows i fremtidige utgivelser.

Geeky OS-sikkerhetsforbedringer skaper ikke akkurat store overskrifter i front-end-fellesskapet, men det er naturlig at passord kommer til å være en "ting". Og med tanke på hvordan passord og passordapper påvirker brukeropplevelsen av ting som autentisering og skjemabehandling, vil vi kanskje i det minste omslutte dem, slik at vi vet hva som kommer.

Det er poenget med denne artikkelen. Jeg har studert og eksperimentert med passord – og WebAuthn API de er bygget på toppen av – i noen tid nå. La meg dele det jeg har lært.

Innholdsfortegnelse

Terminologi

Her er den obligatoriske delen av terminologien du kommer til å ønske å vite når vi graver i. Som de fleste teknologier, er adgangsnøkler laget med esoteriske ord og akronymer som ofte er veisperrer for forståelse. Jeg skal prøve å avmystifisere flere for deg her.

• Stolende fest: serveren du vil autentisere mot. Vi bruker "server" for å antyde den pålitelige parten i denne artikkelen.
• Klient: i vårt tilfelle, nettleseren eller operativsystemet.
• Autentisering: Programvare og/eller maskinvareenheter som tillater generering og lagring for offentlige nøkkelpar.
• FIDO: Et åpent standardorgan som også lager spesifikasjoner rundt FIDO-legitimasjon.
• WebAuthn: Den underliggende protokollen for passord, også kjent som en FIDO2 legitimasjon eller FIDO-legitimasjon for én enhet.
• adgangsnøkler: WebAuthn, men med skysynkronisering (også kalt FIDO-legitimasjon for flere enheter, identifiserbar legitimasjon eller innbyggerlegitimasjon).
• Offentlig nøkkelkryptering: Et generert nøkkelpar som inkluderer en privat og offentlig nøkkel. Avhengig av algoritmen, bør den enten brukes til signering og verifisering eller kryptering og dekryptering. Dette er også kjent som asymmetrisk kryptografi.
• RSA: Et akronym av skapernes navn, Rivest Shamir og Adel. RSA er en eldre, men fortsatt nyttig, familie av offentlig nøkkelkryptografi basert på factoring-primtal.
• Elliptisk kurvekryptering (ECC): En nyere familie av kryptografi basert på elliptiske kurver.
• ES256: En offentlig nøkkel med elliptisk kurve som bruker en ECDSA-signeringsalgoritme (PDF) med SHA256 for hashing.
• RS256: Som ES256, men den bruker RSA med RSASSA-PKCS1-v1.5 og SHA256.

Hva er passord?

Før vi kan snakke spesifikt om passord, må vi snakke om en annen protokoll kalt WebAuthn (også kjent som FIDO2). Passnøkler er en spesifikasjon som er bygget på toppen av WebAuthn. WebAuthn tillater offentlig nøkkelkryptering for å erstatte passord. Vi bruker en slags sikkerhetsenhet, for eksempel en maskinvarenøkkel eller Trusted Platform Module (TPM), for å lage private og offentlige nøkler.

Den offentlige nøkkelen er for alle å bruke. Den private nøkkelen kan imidlertid ikke fjernes fra enheten som genererte den. Dette var et av problemene med WebAuthn; hvis du mister enheten, mister du tilgangen.

Passnøkler løser dette ved å gi en skysynkronisering av legitimasjonen din. Med andre ord, det du genererer på datamaskinen din kan nå også brukes på telefonen din (selv om det er forvirrende nok påloggingsinformasjon for én enhet også).

For øyeblikket, i skrivende stund, er det bare iOS, macOS og Android som gir full støtte for skysynkroniserte passord, og selv da er de begrenset av nettleseren som brukes. Google og Apple tilbyr et grensesnitt for synkronisering via deres Google Password Manager og Apple iCloud nøkkelring tjenester, henholdsvis.

Hvordan erstatter passord passord?

I offentlig nøkkelkryptering kan du utføre det som kalles signering. Signering tar et stykke data og kjører det deretter gjennom en signeringsalgoritme med den private nøkkelen, hvor den deretter kan verifiseres med den offentlige nøkkelen.

Hvem som helst kan generere et offentlig nøkkelpar, og det kan ikke tilskrives noen person siden enhver person kunne ha generert det i utgangspunktet. Det som gjør det nyttig er at bare data signert med den private nøkkelen kan verifiseres med den offentlige nøkkelen. Det er den delen som erstatter et passord — en server lagrer den offentlige nøkkelen, og vi logger på ved å bekrefte at vi har den andre halvdelen (f.eks. privat nøkkel), ved å signere en tilfeldig utfordring.

Som en ekstra fordel, siden vi lagrer brukerens offentlige nøkler i en database, er det ikke lenger bekymring for passordbrudd som påvirker millioner av brukere. Dette reduserer phishing, brudd og en rekke andre sikkerhetsproblemer som vår passordavhengige verden står overfor. Hvis en database brytes, er alt dette lagret i brukerens offentlige nøkler, noe som gjør den praktisk talt ubrukelig for en angriper.

Ikke flere glemte e-poster og tilhørende passord heller! Nettleseren vil huske hvilken legitimasjon du brukte for hvilket nettsted – alt du trenger å gjøre er å foreta et par klikk, og du er logget på. Du kan gi en sekundær verifiseringsmåte for å bruke passordet, for eksempel biometri eller en pinkode , men de er fortsatt mye raskere enn passordene fra før.

Mer om kryptografi

Offentlig nøkkelkryptering innebærer å ha en privat og en offentlig nøkkel (kjent som et nøkkelpar). Nøklene genereres sammen og har separate bruksområder. For eksempel er den private nøkkelen ment å holdes hemmelig, og den offentlige nøkkelen er ment for den du vil utveksle meldinger med.

Når det gjelder kryptering og dekryptering av en melding, brukes mottakerens offentlige nøkkel til å kryptere en melding slik at kun mottakerens private nøkkel kan dekryptere meldingen. På sikkerhetsspråk er dette kjent som "å gi konfidensialitet". Dette gir imidlertid ikke bevis på at avsenderen er den de sier de er, siden hvem som helst kan bruke en offentlig nøkkel til å sende en kryptert melding til noen.

Det er tilfeller der vi må bekrefte at en melding faktisk kom fra avsenderen. I disse tilfellene bruker vi signering og signaturverifisering for å sikre at avsenderen er den de sier de er (også kjent som autentisitet). I offentlig nøkkel (også kalt asymmetrisk) kryptografi, gjøres dette vanligvis ved å signere hashen til en melding, slik at bare den offentlige nøkkelen kan bekrefte den korrekt. Hash-en og avsenderens private nøkkel produserer en signatur etter å ha kjørt den gjennom en algoritme, og deretter kan hvem som helst bekrefte at meldingen kom fra avsenderen med avsenderens offentlige nøkkel.

Hvordan får vi tilgang til passord?

For å få tilgang til passord, må vi først generere og lagre dem et sted. Noe av denne funksjonaliteten kan leveres med en autentisering. An autentifikatoren er enhver maskinvare- eller programvarestøttet enhet som gir mulighet for kryptografisk nøkkelgenerering. Tenk på de engangspassordene du får fra Google Authenticator, 1Passwordeller LastPass, Blant andre.

For eksempel kan en programvareautentisering bruke Trusted Platform Module (TPM) eller sikker enklave av en enhet for å opprette legitimasjon. Legitimasjonen kan deretter lagres eksternt og synkroniseres på tvers av enheter, f.eks. passord. En maskinvareautentisering vil være noe sånt som en YubiKey, som kan generere og lagre nøkler på selve enheten.

For å få tilgang til autentiseringen må nettleseren ha tilgang til maskinvare, og for det trenger vi et grensesnitt. Grensesnittet vi bruker her er Client to Authenticator Protocol (CTAP). Det gir tilgang til forskjellige autentiseringsenheter over forskjellige mekanismer. For eksempel kan vi få tilgang til en autentisering via NFC, USB og Bluetooth ved å bruke CTAP.

En av de mer interessante måtene å bruke adgangsnøkler på er å koble telefonen over Bluetooth til en annen enhet som kanskje ikke støtter passord. Når enhetene er paret over Bluetooth, kan jeg logge på nettleseren på datamaskinen min ved å bruke telefonen som mellomledd!

Forskjellen mellom passord og WebAuthn

Adgangsnøkler og WebAuthn-nøkler er forskjellige på flere måter. For det første regnes adgangsnøkler som legitimasjon for flere enheter og kan synkroniseres på tvers av enheter. Derimot er WebAuthn-nøkler en enkeltenhetslegitimasjon - en fancy måte å si at du er bundet til én enhet for verifisering.

For det andre, for å autentisere til en server, må WebAuthn-nøkler gi brukerhåndtaket for pålogging, hvoretter en allowCredentials Listen returneres til klienten fra serveren, som informerer om hvilke påloggingsopplysninger som kan brukes til å logge på. Passnøkler hopper over dette trinnet og bruker serverens domenenavn for å vise hvilke nøkler som allerede er bundet til det nettstedet. Du kan velge passordet som er knyttet til den serveren, som det allerede er kjent av systemet ditt.

Ellers er nøklene kryptografisk de samme; de er bare forskjellige i hvordan de lagres og hvilken informasjon de bruker for å starte påloggingsprosessen.

Prosessen... i et nøtteskall

Prosessen for å generere en WebAuthn eller en adgangsnøkkel er veldig lik: få en utfordring fra serveren og bruk deretter navigator.credentials.create web-API for å generere et offentlig nøkkelpar. Send deretter utfordringen og den offentlige nøkkelen tilbake til serveren som skal lagres.

Ved mottak av den offentlige nøkkelen og utfordringen, validerer serveren utfordringen og økten den ble opprettet fra. Hvis det sjekkes ut, lagres den offentlige nøkkelen, så vel som all annen relevant informasjon som brukeridentifikatoren eller attestasjonsdata, i databasen.

Brukeren har ett trinn til — hent en ny utfordring fra serveren og bruk navigator.credentials.get API for å signere utfordringen. Vi sender tilbake den signerte utfordringen til serveren, og serveren bekrefter utfordringen, og logger oss deretter på hvis signaturen går igjennom.

Det er selvfølgelig mye mer til hvert trinn. Men det er vanligvis slik vi logger på et nettsted ved hjelp av WebAuthn eller passord.

Kjøttet og potetene

Adgangsnøkler brukes i to forskjellige faser: attestasjon og påstand faser.

Attestasjonsfasen kan også betraktes som registreringsfasen. Du vil registrere deg med en e-post og et passord for et nytt nettsted, men i dette tilfellet vil vi bruke passordet vårt.

Påstandsfasen ligner på hvordan du logger på et nettsted etter at du har registrert deg.

attestasjon

De navigator.credentials.create API er fokus i attestasjonsfasen vår. Vi er registrert som en ny bruker i systemet og trenger å generere et nytt offentlig nøkkelpar. Vi må imidlertid spesifisere hva slags nøkkelpar vi ønsker å generere. Det betyr at vi må tilby alternativer 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

Vi får det PublicKeyCredential som inneholder en AuthenticatorAttestationResponse som kommer tilbake etter opprettelsen. Legitimasjonen har IDen til det genererte nøkkelparet.

Svaret gir et par biter nyttig informasjon. Først har vi vår offentlige nøkkel i dette svaret, og vi må sende det til serveren som skal lagres. For det andre får vi også tilbake clientDataJSON eiendom som vi kan dekode, og derfra få tilbake type, challengeog origin av passordet.

For attestering ønsker vi å validere type, challengeog origin på serveren, samt lagre den offentlige nøkkelen med sin identifikator, f.eks. kid. Vi kan også valgfritt lagre attestationObject hvis vi ønsker det. En annen nyttig egenskap å lagre er COSE algoritme, som er definert ovenfor i vår  PublicKeyCredentialCreationOptions med alg: -7 or alg: -256, for enkelt å verifisere eventuelle signerte utfordringer i påstandsfasen.

Påstand

De navigator.credentials.get API vil være fokus for påstandsfasen. Konseptuelt vil det være her brukeren logger på nettapplikasjonen etter å ha registrert seg.

// 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

Vi får igjen en PublicKeyCredential med en AuthenticatorAssertionResponse denne gangen. Påloggingsinformasjonen inkluderer igjen nøkkelidentifikatoren.

Vi får også type, challengeog origin fra clientDataJSON en gang til. De signature er nå inkludert i svaret, samt authenticatorData. Vi trenger de og de clientDataJSON for å bekrefte at dette ble signert med den private nøkkelen.

De authenticatorData inkluderer noen egenskaper som er verdt å spore. Først er SHA256-hashen til opprinnelsen du bruker, plassert innenfor de første 32 bytene, noe som er nyttig for å bekrefte at forespørselen kommer fra samme opprinnelsesserver. Det andre er signCount, som er fra byte 33 til 37. Dette genereres fra autentiseringsverktøyet og bør sammenlignes med dens tidligere verdi for å sikre at det ikke skjer noe skummelt med nøkkelen. Verdien skal alltid være 0 når det er en adgangsnøkkel for flere enheter, og bør være tilfeldig større enn det forrige signCount når det er en passordnøkkel for én enhet.

Når du har hevdet påloggingen din, bør du være logget inn - Gratulerer! Passkeys er en ganske flott protokoll, men den kommer med noen forbehold.

Noen ulemper

Det er mange fordeler med adgangsnøkler, men det er noen problemer med det når dette skrives. For det første er adgangsnøkler fortsatt noe tidlig støttemessig, med kun legitimasjon for én enhet tillatt på Windows og svært lite støtte for Linux-systemer. Passkeys.dev gir en fint bord som ligner på Caniuse i denne protokollen.

Dessuten kommuniserer ikke Googles og Apples passordplattformer med hverandre. Hvis du ønsker å få legitimasjonen din fra Android-telefonen din over til iPhone ... vel, du er uheldig for nå. Det er ikke dermed sagt at det ikke er interoperabilitet! Du kan logge på datamaskinen din ved å bruke telefonen som autentisering. Men det ville vært mye renere bare å ha det innebygd i operativsystemet og synkronisert uten at det er låst på leverandørnivå.

Hvor går ting?

Hvordan ser fremtidens passordprotokoll ut? Det ser ganske bra ut! Når den får støtte fra flere operativsystemer, bør det være et oppsving i bruken, og du vil begynne å se den brukes mer og mer i naturen. Noen passord ledere kommer til og med å støtte dem på førstehånd.

Passnøkler støttes på ingen måte bare på nettet. Android og iOS vil både støtte innfødte passord som førsteklasses borgere. Vi er fortsatt i de tidlige dagene av alt dette, men forventer å se det nevnt mer og mer.

Tross alt eliminerer vi behovet for passord, og ved å gjøre det gjør vi verden tryggere for det!

Ressurser

Her er noen flere ressurser hvis du vil lære mer om adgangsnøkler. Det er også et depot og en demo jeg har satt sammen for denne artikkelen.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://css-tricks.com/passkeys-what-the-heck-and-why/