Sleutels: wat maakt het uit en waarom?

Deze dingen heetten wachtwoorden maken tegenwoordig zeker de ronde. Ze waren een belangrijke attractie bij W3CTPAC 2022, kreeg steun in Safari 16, vinden hun weg naar macOS en iOS, en zijn gepland om te zijn de toekomst voor wachtwoordmanagers zoals 1Password. Zij zijn al ondersteund in Android, en zullen binnenkort hun weg vinden naar Chrome OS en Windows in toekomstige releases.

Geeky OS-beveiligingsverbeteringen halen niet echt de krantenkoppen in de front-end-community, maar het spreekt voor zich dat wachtwoordsleutels een "ding" zullen worden. En als we bedenken hoe wachtwoorden en wachtwoord-apps de gebruikerservaring van zaken als authenticatie en formulierverwerking beïnvloeden, willen we er misschien op zijn minst omheen wikkelen, zodat we weten wat er gaat komen.

Dat is het punt van dit artikel. Ik ben al een tijdje bezig met het bestuderen en experimenteren met wachtwoordsleutels - en de WebAuthn API waarop ze zijn gebouwd. Laat me delen wat ik heb geleerd.

Inhoudsopgave

Terminologie

Hier is het verplichte gedeelte van de terminologie die je wilt weten terwijl we graven. Zoals de meeste technologie, zijn wachtwoordsleutels gemaakt met esoterische woorden en acroniemen die vaak wegversperringen zijn voor begrip. Ik zal hier verschillende voor u proberen te demystificeren.

• Vertrouwende partij: de server waarmee u zich authenticeert. In dit artikel gebruiken we 'server' om de Relying Party aan te duiden.
• Opdrachtgever: in ons geval de webbrowser of het besturingssysteem.
• Authenticator: Software- en/of hardwareapparaten die het genereren en opslaan van openbare sleutelparen mogelijk maken.
• FIDO: Een instantie voor open standaarden die ook specificaties opstelt rond FIDO-referenties.
• WebAuthen: Het onderliggende protocol voor wachtwoordsleutels, ook wel bekend als a FIDO2 inloggegevens of FIDO-inloggegevens voor één apparaat.
• Wachtwoorden: WebAuthn, maar met cloudsynchronisatie (ook FIDO-inloggegevens voor meerdere apparaten, vindbare inloggegevens of residente inloggegevens genoemd).
• Cryptografie met openbare sleutel: Een gegenereerd sleutelpaar dat een private en publieke sleutel bevat. Afhankelijk van het algoritme moet het worden gebruikt voor ondertekening en verificatie of voor versleuteling en ontsleuteling. Dit wordt ook wel genoemd asymmetrische cryptografie.
• RSA: Een acroniem van de namen van de makers, Rivest Shamir en Adel. RSA is een oudere, maar nog steeds bruikbare familie van cryptografie met openbare sleutels op basis van priemgetallen.
• Elliptische curve-cryptografie (ECC): Een nieuwere familie van cryptografie gebaseerd op elliptische krommen.
• ES256: Een openbare sleutel met een elliptische curve die gebruikmaakt van een ECDSA-ondertekeningsalgoritme (PDF) Met SHA256 voor hashing.
• RS256: Zoals ES256, maar het gebruikt RSA met RSASSA-PKCS1-v1.5 en SHA256.

Wat zijn sleutels?

Voordat we specifiek over wachtwoordsleutels kunnen praten, moeten we het hebben over een ander protocol genaamd WebAuthen (ook bekend als FIDO2). Passkeys zijn een specificatie die bovenop WebAuthn is gebouwd. WebAuthn maakt cryptografie met openbare sleutels mogelijk om wachtwoorden te vervangen. We gebruiken een soort beveiligingsapparaat, zoals een hardwaresleutel of Trusted Platform Module (TPM), om privé- en openbare sleutels te maken.

De publieke sleutel is voor iedereen te gebruiken. De privésleutel kan echter niet worden verwijderd van het apparaat dat deze heeft gegenereerd. Dit was een van de problemen met WebAuthn; als u het apparaat verliest, verliest u de toegang.

Passkeys lost dit op door een cloudsynchronisatie van uw inloggegevens te bieden. Met andere woorden, wat u op uw computer genereert, kan nu ook op uw telefoon worden gebruikt (hoewel het verwarrend is dat er ook inloggegevens voor één apparaat zijn).

Momenteel bieden op het moment van schrijven alleen iOS, macOS en Android volledige ondersteuning voor cloud-gesynchroniseerde toegangssleutels, en zelfs dan worden ze beperkt door de gebruikte browser. Google en Apple bieden een interface voor synchronisatie via hun Google-wachtwoordbeheerder en Apple iCloud-sleutelhanger respectievelijke diensten.

Hoe vervangen wachtwoorden wachtwoorden?

Bij cryptografie met openbare sleutels kunt u uitvoeren wat bekend staat als het ondertekenen van. Bij het ondertekenen wordt een stuk gegevens genomen en door een ondertekeningsalgoritme geleid met de privésleutel, waar het vervolgens kan worden geverifieerd met de openbare sleutel.

Iedereen kan een openbaar sleutelpaar genereren en het is niet toe te schrijven aan een persoon, aangezien een persoon het in de eerste plaats had kunnen genereren. Wat het handig maakt, is dat alleen gegevens die zijn ondertekend met de privésleutel, kunnen worden geverifieerd met de openbare sleutel. Dat is het gedeelte dat een wachtwoord vervangt — een server slaat de openbare sleutel op en we loggen in door te verifiëren dat we de andere helft hebben (bijv. privésleutel), door een willekeurige uitdaging te ondertekenen.

Als bijkomend voordeel, aangezien we de openbare sleutels van de gebruiker opslaan in een database, is er geen bezorgdheid meer over wachtwoordinbreuken die miljoenen gebruikers treffen. Dit vermindert phishing, inbreuken en een hele reeks andere beveiligingsproblemen waarmee onze wachtwoordafhankelijke wereld momenteel wordt geconfronteerd. Als een database wordt geschonden, wordt dat allemaal opgeslagen in de openbare sleutels van de gebruiker, waardoor het vrijwel onbruikbaar wordt voor een aanvaller.

Ook geen vergeten e-mails en bijbehorende wachtwoorden meer! De browser onthoudt welke inloggegevens u voor welke website heeft gebruikt. U hoeft alleen maar een paar keer te klikken en u bent ingelogd. U kunt een secundair verificatiemiddel opgeven om de toegangscode te gebruiken, zoals biometrische gegevens of een pincode. , maar die zijn nog steeds veel sneller dan de wachtwoorden van vroeger.

Meer over cryptografie

Cryptografie met openbare sleutels omvat het hebben van een privésleutel en een openbare sleutel (bekend als een sleutelpaar). De sleutels worden samen gegenereerd en hebben een afzonderlijk gebruik. Zo is de private sleutel bedoeld om geheim te houden en is de publieke sleutel bedoeld voor degene met wie je berichten wilt uitwisselen.

Als het gaat om het versleutelen en ontsleutelen van een bericht, wordt de openbare sleutel van de ontvanger gebruikt om een ​​bericht te versleutelen, zodat alleen de persoonlijke sleutel van de ontvanger het bericht kan ontsleutelen. In veiligheidstermen staat dit bekend als "het verstrekken van vertrouwelijkheid". Dit is echter geen bewijs dat de afzender is wie hij zegt dat hij is, aangezien iedereen een openbare sleutel kan gebruiken om iemand een gecodeerd bericht te sturen.

Er zijn gevallen waarin we moeten verifiëren dat een bericht inderdaad afkomstig is van de afzender. In deze gevallen gebruiken we ondertekening en handtekeningverificatie om ervoor te zorgen dat de afzender is wie hij zegt dat hij is (ook bekend als echtheid). In openbare sleutel (ook wel asymmetrisch) cryptografie, wordt dit over het algemeen gedaan door de hash van een bericht te ondertekenen, zodat alleen de openbare sleutel het correct kan verifiëren. De hash en de privésleutel van de afzender produceren een handtekening nadat ze door een algoritme zijn gegaan, en vervolgens kan iedereen verifiëren dat het bericht van de afzender kwam met de openbare sleutel van de afzender.

Hoe krijgen we toegang tot wachtwoorden?

Om toegang te krijgen tot wachtwoordsleutels, moeten we ze eerst genereren en ergens opslaan. Een deel van deze functionaliteit kan worden voorzien van een authenticator. Een Authenticator is elk door hardware of software ondersteund apparaat dat de mogelijkheid biedt voor het genereren van cryptografische sleutels. Denk aan die eenmalige wachtwoorden die je krijgt Google Authenticator, 1Passwordof LastPass.

Een software-authenticator kan bijvoorbeeld de Trusted Platform Module (TPM) of beveiligde enclave van een apparaat gebruiken om inloggegevens te maken. De inloggegevens kunnen vervolgens op afstand worden opgeslagen en op verschillende apparaten worden gesynchroniseerd, bijvoorbeeld toegangssleutels. Een hardware-authenticator zou zoiets zijn als een YubiKey, die sleutels op het apparaat zelf kan genereren en opslaan.

Om toegang te krijgen tot de authenticator, moet de browser toegang hebben tot hardware en daarvoor hebben we een interface nodig. De interface die we hier gebruiken is het Client to Authenticator Protocol (CTAP). Het geeft toegang tot verschillende authenticators via verschillende mechanismen. We hebben bijvoorbeeld toegang tot een authenticator via NFC, USB en Bluetooth door gebruik te maken van CTAP.

Een van de interessantere manieren om wachtwoordsleutels te gebruiken, is door uw telefoon via Bluetooth te verbinden met een ander apparaat dat mogelijk geen wachtwoordsleutels ondersteunt. Wanneer de apparaten via Bluetooth zijn gekoppeld, kan ik inloggen op de browser op mijn computer met mijn telefoon als tussenpersoon!

Het verschil tussen wachtwoordsleutels en WebAuthn

Passkeys en WebAuthn-sleutels verschillen op verschillende manieren. Ten eerste worden wachtwoordsleutels beschouwd als inloggegevens voor meerdere apparaten en kunnen ze op verschillende apparaten worden gesynchroniseerd. WebAuthn-sleutels daarentegen zijn inloggegevens voor één apparaat - een mooie manier om te zeggen dat u voor verificatie aan één apparaat gebonden bent.

Ten tweede, om te authenticeren bij een server, moeten WebAuthn-sleutels de gebruikersingang bieden voor inloggen, waarna een allowCredentials lijst wordt teruggestuurd naar de client vanaf de server, die informeert welke inloggegevens kunnen worden gebruikt om in te loggen. Passkeys slaan deze stap over en gebruiken de domeinnaam van de server om te laten zien welke sleutels al aan die site zijn gekoppeld. U kunt de toegangssleutel selecteren die aan die server is gekoppeld, zoals deze al bekend is bij uw systeem.

Anders zijn de sleutels cryptografisch hetzelfde; ze verschillen alleen in hoe ze worden opgeslagen en welke informatie ze gebruiken om het inlogproces te starten.

Het proces... in een notendop

Het proces voor het genereren van een WebAuthn of een wachtwoord lijkt erg op elkaar: krijg een uitdaging van de server en gebruik vervolgens de navigator.credentials.create web-API om een ​​openbaar sleutelpaar te genereren. Stuur vervolgens de uitdaging en de openbare sleutel terug naar de server om te worden opgeslagen.

Na ontvangst van de openbare sleutel en uitdaging, valideert de server de uitdaging en de sessie van waaruit deze is gemaakt. Als dat klopt, wordt de openbare sleutel opgeslagen, evenals alle andere relevante informatie zoals de gebruikers-ID of attestgegevens, in de database.

De gebruiker heeft nog een stap: haal nog een uitdaging op van de server en gebruik de navigator.credentials.get API om de uitdaging te ondertekenen. We sturen de ondertekende uitdaging terug naar de server, en de server verifieert de uitdaging en logt ons in als de handtekening slaagt.

Natuurlijk komt er bij elke stap meer kijken. Maar dat is over het algemeen hoe we inloggen op een website met behulp van WebAuthn of wachtwoorden.

Het vlees en de aardappelen?

Wachtwoordsleutels worden in twee verschillende fasen gebruikt: de getuigenis en bewering fasen.

De attestfase kan ook worden gezien als de registratiefase. U meldt zich aan met een e-mailadres en wachtwoord voor een nieuwe website, maar in dit geval gebruiken we onze toegangscode.

De bevestigingsfase is vergelijkbaar met de manier waarop u zich aanmeldt bij een website nadat u zich heeft aangemeld.

getuigenis

De navigator.credentials.create API is de focus van onze attestfase. We zijn geregistreerd als een nieuwe gebruiker in het systeem en moeten een nieuw openbaar sleutelpaar genereren. We moeten echter specificeren wat voor soort sleutelpaar we willen genereren. Dat betekent dat we opties moeten bieden 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

We zullen krijgen PublicKeyCredential die een bevat AuthenticatorAttestationResponse dat komt terug na creatie. De referentie heeft de ID van het gegenereerde sleutelpaar.

Het antwoord bevat een paar stukjes nuttige informatie. Ten eerste hebben we onze openbare sleutel in dit antwoord en moeten we die naar de server sturen om te worden opgeslagen. Ten tweede krijgen we ook de clientDataJSON eigenschap die we kunnen decoderen, en van daaruit de type, challenge en origin van de toegangscode.

Voor attestatie willen we de type, challenge en origin op de server, en bewaar de openbare sleutel met zijn identificatiecode, bijvoorbeeld kid. Eventueel kunnen we de attestationObject als we dat willen. Een andere handige eigenschap om op te slaan is de COSE algoritme, dat hierboven is gedefinieerd in onze  PublicKeyCredentialCreationOptions Met alg: -7 or alg: -256, om eventuele ondertekende uitdagingen in de beweringsfase eenvoudig te verifiëren.

bewering

De navigator.credentials.get API zal de focus zijn van de assertion-fase. Conceptueel zou dit zijn waar de gebruiker zich aanmeldt bij de webapplicatie nadat hij zich heeft aangemeld.

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

We krijgen weer een PublicKeyCredential een AuthenticatorAssertionResponse deze keer. De referentie bevat opnieuw de sleutelidentificatie.

We krijgen ook de type, challenge en origin van het clientDataJSON nog een keer. De signature is nu opgenomen in het antwoord, evenals de authenticatorData. Die hebben we nodig en de clientDataJSON om te verifiëren dat deze is ondertekend met de privésleutel.

De authenticatorData bevat een aantal eigenschappen die de moeite waard zijn om te volgen Ten eerste is de SHA256-hash van de oorsprong die u gebruikt, die zich binnen de eerste 32 bytes bevindt, wat handig is om te verifiëren dat het verzoek afkomstig is van dezelfde oorspronkelijke server. Ten tweede is de signCount, dat is van byte 33 tot 37. Dit wordt gegenereerd door de authenticator en moet worden vergeleken met de vorige waarde om ervoor te zorgen dat er niets vreemds aan de hand is met de sleutel. De waarde moet altijd 0 zijn als het een wachtwoordsleutel voor meerdere apparaten is en moet willekeurig groter zijn dan de vorige signCount als het een wachtwoordsleutel voor één apparaat is.

Zodra u uw login heeft bevestigd, zou u ingelogd moeten zijn — gefeliciteerd! Passkeys is een behoorlijk goed protocol, maar er zijn enkele kanttekeningen bij.

Enkele nadelen

Passkeys heeft veel positieve kanten, maar er zijn op het moment van schrijven enkele problemen mee. Om te beginnen is passkeys wat betreft ondersteuning nog wat vroeg, met alleen inloggegevens voor één apparaat toegestaan ​​op Windows en heel weinig ondersteuning voor Linux-systemen. Wachtwoorden.dev biedt mooie tafel die een beetje lijkt op de Caniuse van dit protocol.

Ook communiceren de wachtwoordsleutelplatforms van Google en Apple niet met elkaar. Als je je inloggegevens van je Android-telefoon naar je iPhone wilt overzetten... nou, dan heb je voorlopig pech. Dat wil niet zeggen dat er geen interoperabiliteit is! U kunt inloggen op uw computer door uw telefoon als authenticator te gebruiken. Maar het zou veel schoner zijn om het gewoon in het besturingssysteem in te bouwen en te synchroniseren zonder dat het op leveranciersniveau wordt vergrendeld.

Waar gaan de dingen heen?

Hoe ziet het wachtwoordprotocol van de toekomst eruit? Het ziet er goed uit! Zodra het ondersteuning krijgt van meer besturingssystemen, zou het gebruik moeten toenemen en zul je zien dat het steeds meer in het wild wordt gebruikt. Sommige wachtwoord managers gaan ze zelfs uit de eerste hand ondersteunen.

Passkeys worden zeker niet alleen op internet ondersteund. Android en iOS zal zowel inheemse toegangssleutels als eersteklas burgers ondersteunen. We staan ​​nog aan het begin van dit alles, maar we verwachten dat het steeds vaker wordt genoemd.

We elimineren immers de behoefte aan wachtwoorden en maken daarmee de wereld veiliger!

Resources

Hier zijn wat meer bronnen als u meer wilt weten over Passkeys. Er is ook een repository en demo die ik voor dit artikel heb samengesteld.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://css-tricks.com/passkeys-what-the-heck-and-why/