Adgangsnøgler: Hvad pokker og hvorfor?

Disse ting kaldes adgangsnøgler sikker på at gøre runderne i disse dage. De var en hovedattraktion kl W3C TPAC 2022, fik opbakning i Safari 16, er ved at finde vej ind macOS og iOS, og er beregnet til at være fremtiden for adgangskodeadministratorer som 1Password. De er allerede understøttet i Android, og vil snart finde vej til Chrome OS og Windows i fremtidige udgivelser.

Nørdede OS-sikkerhedsforbedringer skaber ikke ligefrem store overskrifter i front-end-fællesskabet, men det er naturligt, at adgangsnøgler bliver en "ting". Og i betragtning af, hvordan adgangskoder og adgangskodeapps påvirker brugeroplevelsen af ​​ting som autentificering og formularbehandling, vil vi måske i det mindste omslutte vores tanker om dem, så vi ved, hvad der kommer.

Det er meningen med denne artikel. Jeg har studeret og eksperimenteret med adgangsnøgler - og WebAuthn API'en, de er bygget oven på - i nogen tid nu. Lad mig dele, hvad jeg har lært.

Indholdsfortegnelse

Terminologi

Her er den obligatoriske del af terminologien, som du gerne vil vide, mens vi graver i. Som de fleste teknologier er adgangsnøgler lavet med esoteriske ord og akronymer, der ofte er vejspærringer for forståelse. Jeg vil prøve at afmystificere flere for dig her.

• Stolende part: serveren du vil godkende mod. Vi bruger "server" til at antyde den afhængige part i denne artikel.
• Klient: i vores tilfælde webbrowseren eller operativsystemet.
• Autentificering: Software og/eller hardwareenheder, der tillader generering og lagring af offentlige nøglepar.
• Fido: Et åbent standardorgan, der også opretter specifikationer omkring FIDO-legitimationsoplysninger.
• WebAuthn: Den underliggende protokol for adgangsnøgler, også kendt som en FIDO2 legitimationsoplysninger eller FIDO-legitimationsoplysninger på én enhed.
• adgangsnøgler: WebAuthn, men med cloud-synkronisering (også kaldet FIDO-legitimationsoplysninger til flere enheder, legitimationsoplysninger, der kan findes eller beboeroplysninger).
• Offentlig nøglekryptering: Et genereret nøglepar, der inkluderer en privat og offentlig nøgle. Afhængigt af algoritmen skal den enten bruges til signering og verifikation eller kryptering og dekryptering. Dette er også kendt som asymmetrisk kryptografi.
• RSA: Et akronym af skabernes navne, Rivest Shamir og Adel. RSA er en ældre, men stadig nyttig, familie af offentlig nøglekryptografi baseret på factoring-primtal.
• Elliptisk kurvekryptering (ECC): En nyere familie af kryptografi baseret på elliptiske kurver.
• ES256: En offentlig elliptisk kurvenøgle, der bruger en ECDSA-signeringsalgoritme (PDF) med SHA256 til hashing.
• RS256: Ligesom ES256, men den bruger RSA med RSASSA-PKCS1-v1.5 og SHA256.

Hvad er adgangsnøgler?

Før vi kan tale specifikt om adgangsnøgler, skal vi tale om en anden protokol kaldet WebAuthn (også kendt som FIDO2). Adgangsnøgler er en specifikation, der er bygget oven på WebAuthn. WebAuthn giver mulighed for offentlig nøglekryptering til at erstatte adgangskoder. Vi bruger en form for sikkerhedsenhed, såsom en hardwarenøgle eller Trusted Platform Module (TPM), for at oprette private og offentlige nøgler.

Den offentlige nøgle er til brug for alle. Den private nøgle kan dog ikke fjernes fra den enhed, der genererede den. Dette var et af problemerne med WebAuthn; hvis du mister enheden, mister du adgang.

Adgangsnøgler løser dette ved at give en cloud-synkronisering af dine legitimationsoplysninger. Med andre ord kan det, du genererer på din computer, nu også bruges på din telefon (selvom der forvirrende nok også er legitimationsoplysninger til en enkelt enhed).

I øjeblikket, i skrivende stund, er det kun iOS, macOS og Android, der yder fuld understøttelse af sky-synkroniserede adgangsnøgler, og selv da er de begrænset af den browser, der bruges. Google og Apple leverer en grænseflade til synkronisering via deres Google Password Manager , Apple iCloud nøglering tjenester, hhv.

Hvordan erstatter adgangsnøgler adgangskoder?

I offentlig nøglekryptering kan du udføre det, der er kendt som signering. Signering tager et stykke data og kører det derefter gennem en signeringsalgoritme med den private nøgle, hvor det så kan verificeres med den offentlige nøgle.

Enhver kan generere et offentligt nøglepar, og det kan ikke tilskrives nogen person, da enhver person kunne have genereret det i første omgang. Det, der gør det nyttigt, er, at kun data, der er signeret med den private nøgle, kan verificeres med den offentlige nøgle. Det er den del, der erstatter en adgangskode — en server gemmer den offentlige nøgle, og vi logger ind ved at bekræfte, at vi har den anden halvdel (f.eks. privat nøgle), ved at underskrive en tilfældig udfordring.

Som en ekstra fordel, da vi gemmer brugerens offentlige nøgler i en database, er der ikke længere bekymring for adgangskodebrud, der påvirker millioner af brugere. Dette reducerer phishing, brud og en række andre sikkerhedsproblemer, som vores adgangskodeafhængige verden i øjeblikket står over for. Hvis en database er brudt, er alt det gemt i brugerens offentlige nøgler, hvilket gør den praktisk talt ubrugelig for en angriber.

Heller ikke flere glemte e-mails og tilhørende adgangskoder! Browseren vil huske, hvilke legitimationsoplysninger du brugte til hvilket websted - alt du skal gøre er at foretage et par klik, og du er logget ind. Du kan angive et sekundært verifikationsmiddel for at bruge adgangsnøglen, såsom biometri eller en pinkode. , men de er stadig meget hurtigere end tidligere års adgangskoder.

Mere om kryptografi

Offentlig nøglekryptering involverer at have en privat og en offentlig nøgle (kendt som et nøglepar). Nøglerne genereres sammen og har separate anvendelser. For eksempel er den private nøgle beregnet til at blive holdt hemmelig, og den offentlige nøgle er beregnet til den, du vil udveksle beskeder med.

Når det kommer til at kryptere og dekryptere en besked, bruges modtagerens offentlige nøgle til at kryptere en besked, så kun modtagerens private nøgle kan dekryptere beskeden. På sikkerhedssprog er dette kendt som "at give fortrolighed". Dette giver dog ikke bevis for, at afsenderen er den, de siger, de er, da enhver potentielt kan bruge en offentlig nøgle til at sende en krypteret besked til nogen.

Der er tilfælde, hvor vi skal bekræfte, at en meddelelse faktisk kom fra dens afsender. I disse tilfælde bruger vi signering og signaturbekræftelse for at sikre, at afsenderen er den, de siger, de er (også kendt som ægthed). I offentlig nøgle (også kaldet asymmetrisk) kryptografi, gøres dette generelt ved at signere hashen af ​​en besked, så kun den offentlige nøgle kan verificere den korrekt. Hash'en og afsenderens private nøgle producerer en signatur efter at have kørt den gennem en algoritme, og så kan enhver bekræfte, at beskeden kom fra afsenderen med afsenderens offentlige nøgle.

Hvordan får vi adgang til adgangsnøgler?

For at få adgang til adgangsnøgler skal vi først generere og gemme dem et sted. Nogle af denne funktionalitet kan forsynes med en autentificering. An Autentificering er enhver hardware- eller softwareunderstøttet enhed, der giver mulighed for kryptografisk nøglegenerering. Tænk på de engangsadgangskoder, du får fra Google Autentificering, 1Password eller  LastPass, Blandt andre.

For eksempel kan en softwaregodkendelse bruge Trusted Platform Module (TPM) eller sikker enklave af en enhed til at oprette legitimationsoplysninger. Legitimationsoplysningerne kan derefter gemmes eksternt og synkroniseres på tværs af enheder, f.eks. adgangsnøgler. En hardware-autentificering ville være noget som en YubiKey, som kan generere og gemme nøgler på selve enheden.

For at få adgang til autentificeringen skal browseren have adgang til hardware, og til det har vi brug for en grænseflade. Den grænseflade, vi bruger her, er CTAP (Client to Authenticator Protocol). Det giver adgang til forskellige autentificeringer over forskellige mekanismer. For eksempel kan vi få adgang til en autentificering via NFC, USB og Bluetooth ved at bruge CTAP.

En af de mere interessante måder at bruge adgangsnøgler på er ved at forbinde din telefon via Bluetooth til en anden enhed, der muligvis ikke understøtter adgangsnøgler. Når enhederne er parret over Bluetooth, kan jeg logge ind i browseren på min computer ved at bruge min telefon som mellemled!

Forskellen mellem adgangsnøgler og WebAuthn

Adgangsnøgler og WebAuthn-nøgler adskiller sig på flere måder. For det første betragtes adgangsnøgler som legitimationsoplysninger til flere enheder og kan synkroniseres på tværs af enheder. I modsætning hertil er WebAuthn-nøgler en enkelt-enhedslegitimationsoplysninger - en smart måde at sige, at du er bundet til én enhed til verifikation.

For det andet, for at godkende til en server, skal WebAuthn-nøgler give brugerhåndtaget til login, hvorefter en allowCredentials liste returneres til klienten fra serveren, som informerer om, hvilke legitimationsoplysninger der kan bruges til at logge ind. Adgangsnøgler springer dette trin over og bruger serverens domænenavn til at vise, hvilke nøgler der allerede er bundet til det pågældende websted. Du er i stand til at vælge den adgangsnøgle, der er knyttet til den server, som den allerede er kendt af dit system.

Ellers er nøglerne kryptografisk de samme; de er kun forskellige i, hvordan de opbevares, og hvilke oplysninger de bruger til at starte login-processen.

Processen... i en nøddeskal

Processen til at generere en WebAuthn eller en adgangsnøgle ligner meget: få en udfordring fra serveren, og brug derefter navigator.credentials.create web-API til at generere et offentligt nøglepar. Send derefter udfordringen og den offentlige nøgle tilbage til serveren, der skal gemmes.

Ved modtagelse af den offentlige nøgle og udfordring validerer serveren udfordringen og den session, hvorfra den blev oprettet. Hvis det tjekker ud, gemmes den offentlige nøgle, såvel som enhver anden relevant information, såsom brugeridentifikation eller attestationsdata, i databasen.

Brugeren har et trin mere — hent endnu en udfordring fra serveren og brug navigator.credentials.get API til at underskrive udfordringen. Vi sender den underskrevne udfordring tilbage til serveren, og serveren verificerer udfordringen og logger os derefter på, hvis signaturen består.

Der er selvfølgelig en del mere til hvert trin. Men det er generelt sådan, vi logger ind på et websted ved hjælp af WebAuthn eller adgangsnøgler.

Kødet og kartoflerne

Adgangsnøgler bruges i to adskilte faser: kursusbevis , påstand faser.

Attestationsfasen kan også opfattes som registreringsfasen. Du vil tilmelde dig med en e-mail og adgangskode til et nyt websted, men i dette tilfælde ville vi bruge vores adgangsnøgle.

Påstandsfasen svarer til, hvordan du ville logge ind på et websted efter tilmelding.

attestering

 navigator.credentials.create API er fokus i vores attestationsfase. Vi er registreret som ny bruger i systemet og skal generere et nyt offentligt nøglepar. Vi skal dog specificere, hvilken slags nøglepar vi vil generere. Det betyder, at vi skal give muligheder for 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 PublicKeyCredential som indeholder en AuthenticatorAttestationResponse der kommer tilbage efter skabelsen. Legitimationsoplysningerne har det genererede nøglepars ID.

Svaret giver et par nyttige oplysninger. For det første har vi vores offentlige nøgle i dette svar, og vi skal sende det til serveren, der skal gemmes. For det andet får vi også tilbage clientDataJSON ejendom, som vi kan afkode, og derfra få tilbage type, challengeog origin af adgangsnøglen.

For attestering ønsker vi at validere type, challengeog origin på serveren, samt gemme den offentlige nøgle med dens identifikator, fx kid. Vi kan også valgfrit opbevare attestationObject hvis vi ønsker det. En anden nyttig egenskab at opbevare er COSE algoritme, som er defineret ovenfor i vores  PublicKeyCredentialCreationOptions med alg: -7 or alg: -256, for nemt at verificere eventuelle signerede udfordringer i påstandsfasen.

Påstand

 navigator.credentials.get API vil være fokus for påstandsfasen. Konceptuelt ville det være her, brugeren logger ind på webapplikationen efter tilmelding.

// 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 igen en PublicKeyCredential med en AuthenticatorAssertionResponse denne gang. Legitimationsoplysningerne inkluderer igen nøgle-id'et.

Vi får også type, challengeog origin fra clientDataJSON igen. Det signature er nu medtaget i svaret, samt den authenticatorData. Vi får brug for dem og dem clientDataJSON for at bekræfte, at dette var signeret med den private nøgle.

 authenticatorData indeholder nogle egenskaber, der er værd at spore. Først er SHA256-hashen for den oprindelse, du bruger, placeret inden for de første 32 bytes, hvilket er nyttigt til at bekræfte, at anmodningen kommer fra den samme oprindelsesserver. Andet er signCount, som er fra byte 33 til 37. Dette genereres fra autentificeringsværktøjet og bør sammenlignes med dets tidligere værdi for at sikre, at der ikke sker noget skumt med nøglen. Værdien skal altid være 0, når det er en adgangsnøgle til flere enheder, og den skal være tilfældigt større end det forrige signCount, når det er en adgangsnøgle på én enhed.

Når du har bekræftet dit login, skal du være logget ind — Tillykke! Adgangsnøgler er en ret god protokol, men den kommer med nogle forbehold.

Nogle ulemper

Der er mange fordele ved adgangsnøgler, men der er nogle problemer med det i skrivende stund. For én ting er adgangsnøgler stadig noget tidligt supportmæssigt, med kun legitimationsoplysninger til en enkelt enhed tilladt på Windows og meget lidt understøttelse af Linux-systemer. Passkeys.dev tilvejebringer en flot bord, der ligner Caniuse i denne protokol.

Desuden kommunikerer Googles og Apples adgangsnøgleplatforme ikke med hinanden. Hvis du ønsker at få dine legitimationsoplysninger fra din Android-telefon over til din iPhone ... ja, du er ikke heldig for nu. Det betyder ikke, at der ikke er interoperabilitet! Du kan logge ind på din computer ved at bruge din telefon som autentificering. Men det ville være meget renere bare at have det indbygget i operativsystemet og synkroniseret uden at det er låst på leverandørniveau.

Hvor går tingene hen?

Hvordan ser fremtidens adgangsnøgleprotokol ud? Det ser ret godt ud! Når først den får støtte fra flere operativsystemer, burde der være en optagelse i brugen, og du vil begynde at se den blive brugt mere og mere i naturen. Nogle adgangskode ledere vil endda støtte dem på første hånd.

Adgangsnøgler er på ingen måde kun understøttet på nettet. Android , iOS vil både understøtte indfødte adgangsnøgler som førsteklasses borgere. Vi er stadig i de tidlige dage af alt dette, men forventer at se det nævnt mere og mere.

Når alt kommer til alt, fjerner vi behovet for adgangskoder, og ved at gøre det, gør vi verden mere sikker for det!

Ressourcer

Her er nogle flere ressourcer, hvis du vil lære mere om adgangsnøgler. Der er også et lager og en demo, jeg har sammensat til denne artikel.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://css-tricks.com/passkeys-what-the-heck-and-why/