Dessa saker kallas lösenord säkerligen gör rundorna dessa dagar. De var en huvudattraktion på W3C TPAC 2022, fick stöd i Safari 16, hittar in i macOS och iOS, och är planerade att vara framtiden för lösenordshanterare som 1Password. Dom är stöds redan i Android, och kommer snart att hitta in i Chrome OS och Windows i framtida utgåvor.

Nördiga OS-säkerhetsförbättringar skapar inte precis stora rubriker i front-end-gemenskapen, men det är naturligt att lösenord kommer att vara en "grej". Och med tanke på hur lösenord och lösenordsappar påverkar användarupplevelsen av saker som autentisering och formulärbearbetning, kanske vi åtminstone vill lägga våra sinnen runt dem, så att vi vet vad som kommer.

Det är poängen med den här artikeln. Jag har studerat och experimenterat med lösenord – och WebAuthn API som de är byggda på – under en tid nu. Låt mig dela med mig av vad jag har lärt mig.

Innehållsförteckning

Terminologi

Här är den obligatoriska delen av terminologin som du kommer att vilja veta när vi gräver i. Liksom de flesta tekniker är lösenord skapade med esoteriska ordspråk och akronymer som ofta är vägspärrar för förståelse. Jag ska försöka avmystifiera flera åt dig här.

• Förlita sig parti: servern du kommer att autentisera mot. Vi kommer att använda "server" för att antyda den förtroende parten i den här artikeln.
• Kund: i vårt fall webbläsaren eller operativsystemet.
• Autentisering: Mjukvara och/eller hårdvaruenheter som tillåter generering och lagring av publika nyckelpar.
• FIDO: Ett öppet standardorgan som också skapar specifikationer kring FIDO-uppgifter.
• WebAuthn: Det underliggande protokollet för lösenord, även känt som en FIDO2 autentiseringsuppgifter eller FIDO-uppgifter för en enhet.
• lösenord: WebAuthn, men med molnsynkronisering (kallas även FIDO-uppgifter för flera enheter, upptäckbara referenser eller inloggningsuppgifter).
• Public Key Kryptografi: Ett genererat nyckelpar som inkluderar en privat och offentlig nyckel. Beroende på algoritmen bör den antingen användas för signering och verifiering eller för kryptering och dekryptering. Detta är också känt som asymmetrisk kryptografi.
• RSA: En akronym av skaparnas namn, Rivest Shamir och Adel. RSA är en äldre, men fortfarande användbar, familj av publik nyckelkryptografi baserad på factoringprimtal.
• Elliptisk kurvkryptering (ECC): En nyare familj av kryptografi baserat på elliptiska kurvor.
• ES256: En offentlig nyckel med elliptisk kurva som använder en ECDSA-signeringsalgoritm (PDF) Med SHA256 för hashing.
• RS256: Som ES256, men den använder RSA med RSASSA-PKCS1-v1.5 och SHA256.

Vad är lösenord?

Innan vi kan prata specifikt om lösenord måste vi prata om ett annat protokoll som kallas WebAuthn (även känd som FIDO2). Nyckelnycklar är en specifikation som är byggd ovanpå WebAuthn. WebAuthn tillåter kryptering med publik nyckel för att ersätta lösenord. Vi använder någon form av säkerhetsanordning, till exempel en hårdvarunyckel eller Trusted Platform Module (TPM), för att skapa privata och publika nycklar.

Den publika nyckeln är för alla att använda. Den privata nyckeln kan dock inte tas bort från enheten som genererade den. Detta var ett av problemen med WebAuthn; om du tappar bort enheten förlorar du åtkomst.

Lösenord löser detta genom att tillhandahålla en molnsynkronisering av dina referenser. Med andra ord, det du genererar på din dator kan nu också användas på din telefon (även om det är förvirrande nog, det finns uppgifter för en enda enhet också).

För närvarande, i skrivande stund, tillhandahåller endast iOS, macOS och Android fullt stöd för molnsynkroniserade lösenord, och även då är de begränsade av webbläsaren som används. Google och Apple tillhandahåller ett gränssnitt för synkronisering via deras Google Password Manager och Apple iCloud nyckelring tjänster, respektive.

Hur ersätter lösenord lösenord?

I kryptografi med publik nyckel kan du utföra vad som kallas signering. Signering tar en bit data och kör den sedan genom en signeringsalgoritm med den privata nyckeln, där den sedan kan verifieras med den publika nyckeln.

Vem som helst kan generera ett publikt nyckelpar, och det kan inte tillskrivas någon person eftersom vilken person som helst kunde ha genererat det från början. Det som gör det användbart är att endast data signerade med den privata nyckeln kan verifieras med den offentliga nyckeln. Det är den del som ersätter ett lösenord — en server lagrar den publika nyckeln, och vi loggar in genom att verifiera att vi har den andra hälften (t.ex. privat nyckel), genom att underteckna en slumpmässig utmaning.

Som en extra fördel, eftersom vi lagrar användarens publika nycklar i en databas, finns det inte längre problem med lösenordsintrång som påverkar miljontals användare. Detta minskar nätfiske, intrång och en rad andra säkerhetsproblem som vår lösenordsberoende värld för närvarande står inför. Om en databas kränks lagras allt detta i användarens publika nycklar, vilket gör den praktiskt taget oanvändbar för en angripare.

Inga fler bortglömda e-postmeddelanden och tillhörande lösenord heller! Webbläsaren kommer ihåg vilka autentiseringsuppgifter du använde för vilken webbplats – allt du behöver göra är att göra ett par klick och du är inloggad. Du kan tillhandahålla ett sekundärt verifieringsmedel för att använda lösenordet, till exempel biometri eller en pinkod , men de är fortfarande mycket snabbare än förra års lösenord.

Mer om kryptografi

Offentlig nyckelkryptering innebär att ha en privat och en offentlig nyckel (känd som ett nyckelpar). Nycklarna genereras tillsammans och har separata användningsområden. Till exempel är den privata nyckeln avsedd att hållas hemlig, och den offentliga nyckeln är avsedd för den du vill utbyta meddelanden med.

När det kommer till att kryptera och dekryptera ett meddelande används mottagarens publika nyckel för att kryptera ett meddelande så att endast mottagarens privata nyckel kan dekryptera meddelandet. På säkerhetsspråk är detta känt som "tillhandahållande av konfidentialitet". Detta ger dock inget bevis på att avsändaren är den de säger sig vara, eftersom vem som helst kan använda en offentlig nyckel för att skicka ett krypterat meddelande till någon.

Det finns fall där vi behöver verifiera att ett meddelande verkligen kom från dess avsändare. I dessa fall använder vi signering och signaturverifiering för att säkerställa att avsändaren är den de säger sig vara (även känd som äktheten). I offentlig nyckel (kallas även asymmetrisk) kryptografi, görs detta i allmänhet genom att signera hashen i ett meddelande, så att endast den publika nyckeln kan verifiera det korrekt. Hashen och avsändarens privata nyckel producerar en signatur efter att ha kört den genom en algoritm, och sedan kan vem som helst verifiera att meddelandet kom från avsändaren med avsändarens publika nyckel.

Hur får vi åtkomst till lösenord?

För att komma åt lösenord måste vi först generera och lagra dem någonstans. En del av denna funktionalitet kan förses med en autentisering. En bestyr är en maskin- eller mjukvarustödd enhet som ger möjlighet till kryptografisk nyckelgenerering. Tänk på de engångslösenord du får från Google Authenticator, 1Password, eller Lastpass, bland andra.

Till exempel kan en mjukvaruautentiseringsanordning använda Trusted Platform Module (TPM) eller säker enklav för en enhet för att skapa autentiseringsuppgifter. Inloggningsuppgifterna kan sedan lagras på distans och synkroniseras mellan enheter, t.ex. lösenord. En hårdvaruautentisering skulle vara något som en YubiKey, som kan generera och lagra nycklar på själva enheten.

För att komma åt autentiseringsverktyget måste webbläsaren ha tillgång till hårdvara, och för det behöver vi ett gränssnitt. Gränssnittet vi använder här är CTAP (Client to Authenticator Protocol). Det ger åtkomst till olika autentiseringsenheter över olika mekanismer. Till exempel kan vi komma åt en autentisering via NFC, USB och Bluetooth genom att använda CTAP.

Ett av de mer intressanta sätten att använda lösenord är genom att ansluta din telefon via Bluetooth till en annan enhet som kanske inte stöder lösenord. När enheterna är ihopparade via Bluetooth kan jag logga in i webbläsaren på min dator med min telefon som mellanhand!

Skillnaden mellan lösenord och WebAuthn

Lösenord och WebAuthn-nycklar skiljer sig åt på flera sätt. För det första betraktas lösenordsnycklar som autentiseringsuppgifter för flera enheter och kan synkroniseras mellan enheter. Däremot är WebAuthn-nycklar autentiseringsuppgifter för en enda enhet - ett fint sätt att säga att du är bunden till en enhet för verifiering.

För det andra, för att autentisera till en server måste WebAuthn-nycklar tillhandahålla användarhandtaget för inloggning, varefter en allowCredentials listan returneras till klienten från servern, som informerar om vilka referenser som kan användas för att logga in. Nyckeln hoppar över det här steget och använder serverns domännamn för att visa vilka nycklar som redan är bundna till den platsen. Du kan välja lösenordet som är associerat med den servern, eftersom det redan är känt av ditt system.

Annars är nycklarna kryptografiskt desamma; de skiljer sig bara åt i hur de lagras och vilken information de använder för att starta inloggningsprocessen.

Processen... i ett nötskal

Processen för att generera en WebAuthn eller en lösenordsnyckel är mycket lik: få en utmaning från servern och använd sedan navigator.credentials.create webb-API för att generera ett publikt nyckelpar. Skicka sedan utmaningen och den publika nyckeln tillbaka till servern som ska lagras.

När servern tar emot den publika nyckeln och utmaningen validerar servern utmaningen och sessionen från vilken den skapades. Om det checkar ut, lagras den publika nyckeln, liksom all annan relevant information som användaridentifierare eller attestdata, i databasen.

Användaren har ett steg till — hämta en annan utmaning från servern och använd navigator.credentials.get API för att underteckna utmaningen. Vi skickar tillbaka den signerade utmaningen till servern, och servern verifierar utmaningen och loggar sedan in oss om signaturen går igenom.

Det finns naturligtvis en hel del mer i varje steg. Men det är i allmänhet hur vi skulle logga in på en webbplats med WebAuthn eller lösenord.

Köttet och potatisen

Nyckeln används i två distinkta faser: intyg och påstående faser.

Attestfasen kan också ses som registreringsfasen. Du skulle registrera dig med en e-postadress och ett lösenord för en ny webbplats, men i det här fallet skulle vi använda vår lösenordsnyckel.

Påståendefasen liknar hur du skulle logga in på en webbplats efter att du registrerat dig.

Intyg

Smakämnen navigator.credentials.create API är i fokus för vår attesteringsfas. Vi är registrerade som en ny användare i systemet och behöver generera ett nytt publikt nyckelpar. Vi måste dock specificera vilken typ av nyckelpar vi vill generera. Det betyder att vi måste erbjuda alternativ 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 innehåller en AuthenticatorAttestationResponse som kommer tillbaka efter skapandet. Autentiseringsuppgifterna har det genererade nyckelparets ID.

Svaret ger ett par användbar information. Först har vi vår publika nyckel i det här svaret, och vi måste skicka den till servern som ska lagras. För det andra får vi också tillbaka clientDataJSON egendom som vi kan avkoda och därifrån få tillbaka type, challengeoch origin av lösenordet.

För attestering vill vi validera type, challengeoch origin på servern, samt lagra den publika nyckeln med dess identifierare, t.ex. kid. Vi kan också valfritt lagra attestationObject om vi vill. En annan användbar egenskap att lagra är COSE algoritm, som definieras ovan i vår  PublicKeyCredentialCreationOptions med alg: -7 or alg: -256, för att enkelt verifiera eventuella signerade utmaningar i påståendefasen.

påstående

Smakämnen navigator.credentials.get API kommer att vara i fokus för påståendefasen. Konceptuellt skulle det vara där användaren loggar in på webbapplikationen efter att ha registrerat sig.

// 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 den här gången. Autentiseringsuppgifterna inkluderar återigen nyckelidentifieraren.

Vi får också type, challengeoch origin från clientDataJSON på nytt. De signature ingår nu i svaret, liksom den authenticatorData. Vi behöver de och de clientDataJSON för att verifiera att detta signerades med den privata nyckeln.

Smakämnen authenticatorData innehåller några egenskaper som är värda att spåra. Först är SHA256-hash för ursprunget du använder, beläget inom de första 32 byten, vilket är användbart för att verifiera att begäran kommer från samma ursprungsserver. För det andra är signCount, som är från byte 33 till 37. Detta genereras från autentiseringsenheten och bör jämföras med dess tidigare värde för att säkerställa att inget skumt händer med nyckeln. Värdet ska alltid vara 0 när det är ett lösenord för flera enheter och bör vara slumpmässigt större än det föregående signCount när det är en lösenordsnyckel för en enhet.

När du har bekräftat din inloggning bör du vara inloggad — grattis! Nyckelnycklar är ett ganska bra protokoll, men det kommer med några varningar.

Några nackdelar

Det finns många fördelar med lösenord, men det finns några problem med det när detta skrivs. För det första är lösenordsnycklar fortfarande något tidigt supportmässigt, med endast en enhetsreferens tillåtna på Windows och mycket lite stöd för Linux-system. Passkeys.dev tillhandahåller en trevligt bord som är ungefär som Caniuse i det här protokollet.

Dessutom kommunicerar inte Googles och Apples lösenordsplattformar med varandra. Om du vill få dina referenser från din Android-telefon över till din iPhone ... ja, du har inte tur för nu. Därmed inte sagt att det inte finns någon interoperabilitet! Du kan logga in på din dator genom att använda din telefon som autentisering. Men det skulle vara mycket renare bara att ha det inbyggt i operativsystemet och synkroniserat utan att det låses på leverantörsnivå.

Vart är det på väg?

Hur ser framtidens lösenordsprotokoll ut? Det ser ganska bra ut! När det väl får stöd från fler operativsystem bör det finnas ett uppsving i användningen, och du kommer att börja se det användas mer och mer i det vilda. Några lösenordshanterare kommer till och med att stötta dem från första hand.

Lösenord stöds på intet sätt bara på webben. Android och iOS kommer både att stödja infödda lösenord som förstklassiga medborgare. Vi är fortfarande i början av allt detta, men förväntar oss att se det nämnas mer och mer.

När allt kommer omkring eliminerar vi behovet av lösenord, och genom att göra det gör vi världen säkrare för det!

Resurser

Här är några fler resurser om du vill lära dig mer om lösenord. Det finns också ett arkiv och en demo som jag satt ihop för den här artikeln.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://css-tricks.com/passkeys-what-the-heck-and-why/