Allt du behöver veta om Passkeys - En framtid utan lösenord

Vill du kunna förklara vad Passkeys är? Vill du förstå i lite mer detalj hur det fungerar “i bakgrunden”? Eller vill du kanske bara kunna förklara, genom analogi, vad Passkeys är för något?

Oavsett så vågar jag påstå att du har kommit helt rätt. Den här artikeln vänder sig nämligen till dig som kanske har hört begreppet Passkeys, men fortfarande inte greppat eller ännu bemödat dig med att studera och förstå det. Artikeln vänder sig också till dig som vill kunna beskriva för familj och vänner varför de ska bry sig, men kanske har du saknat lämpliga analogier för att kunna övertyga?

Däremot vänder sig den här artikeln INTE till dig som funderar på att använda Passkeys på arbetsplatsen, eftersom vi då behöver utöka diskussionen och beskrivningarna vilket jag inte avser göra just nu. Användningen av Passkeys inom Enterprise är också ganska så nytt vilket i sig är en anledning att separera den diskussionen från den här artikeln.

OBS: Specifikationerna innehåller en hyfsad mängd detaljer som ger flera om, men och utifallatt-så-visst-jorå-så-att-jo-men-okej situationer. Den här artikeln gör inte anspråk på att redogöra för alla detaljer. Vill du verkligen grotta ner dig, se referenserna för alla relevanta specifikationer och förbered dig på blödande ögon. Du har blivit varnad!

Passkeys på mindre än 30 sekunder

Passkeys ger dig helt lösenordsfria inloggningar. Och det är framförallt lösenordsfria inloggningar på webben som dominerar användningsfallen. Det är faktiskt nästan precis så bra som det låter.

När du registrerar dig på en sajt som stödjer Passkeys skapar du en unik kombination av digitala nycklar som bara kan användas precis där du registrerat dig. När du försöker logga in används den här unika kombinationen av nycklar på ett smart sätt som gör att du bevisar att du är du, och vips så är du inne. Kombinationen av nycklar lagras antingen i mobilen, webbläsaren, operativsystemet, eller på externa hårdvaruenheter.

Passkeys löser i princip helt och hållet de flesta typerna av vanliga angreppstekniker som vanligtvis används mot lösenord som nätfiske, bruteforce och lösenordsgissningar. Vissa typer av hot kvarstår som t.ex. fysiska hot, och under vissa omständigheter skadlig kod. Men de fysiska hoten får vi ändå anse vara en helt annan dimension av utmaningar vi inte behöver lösa med Passkeys.

Du har antagligen redan stöd för Passkeys i både din mobil och webbläsare. Och det var Passkeys på 30 sekunder, grattis.

Summerat i fem punkter

Den absoluta essensen av den här artikeln är följande:

Passkeys är den idag absolut mest konkreta möjligheten att lämna lösenord bakom oss.
Passkeys skyddar nästan helt mot många vanligt förekommande typer av angreppstekniker som t.ex. Phishing, Credential Stuffing, eller Bruteforcing.
Passkeys är faktiskt enkelt till ytan, även om det döljer sig mycket teknik i bakgrunden.
Passkeys är nästan magiskt, men nej… det finns fortfarande saker kvar att oroa sig för, som skadlig kod t.ex.
Passkeys är ett marknadsföringsbegrepp, det finns ingenting som heter så i specifikationerna.

En analogi utan teknisk jargong

Passkeys använder något som heter public key cryptography, och eftersom vi redan här tappat ungefär 95% av alla läsare tycker jag vi skippar det. Låt mig istället försöka förklara Passkeys utan att använda tekniska och kryptiska begrepp.

Föreställ dig att du arbetar som journalist och vill kunna ta emot hemlisar. Du vill vara säker på att när någon skickar en låda med hemlisar, är det bara du som kan öppna den. Det du bestämmer dig för att göra är att lämna ut hänglås som endast kan öppnas med en specifik nyckel, och den nyckeln har bara du. När låset väl är stängt, ja då är det stängt.

Nu säger vi att någon vill skicka en hemlis till dig, hur gör dom då? Först plockar de fram en låda lägger i hemlisen, sätter på hänglåset och skickar iväg lådan.

När du senare tar emot lådan tar du fram din nyckel och öppnar hänglåset eftersom du är den enda som har nyckeln.

Detta är Passkeys; nycklar som bara du har, och hänglås du delar ut för att kunna ta emot meddelanden. Låt mig nu ta ett något mer “modernt” exempel och så som det förhåller sig till inloggningar på webben.

Du vill kunna logga in på Google Mail med en Passkey. Du skapar en nyckel och ett hänglås, som är unikt för Google Mail, och hänglåset ger du till Google Mail.

När du senare vill logga in på Google Mail kommer dom skriva ett hemligt meddelande som de stoppar i en låda och sedan låser med hänglåset. Du tar emot lådan, öppnar det (eftersom du har nyckeln) och berättar för Google mail vad det står i det hemliga meddelandet. Eftersom endast du har nyckeln har du också bevisat att du är du och de släpper in dig i värmen.

Och så gör du för alla ställen där du vill använda Passkeys. Du skapar en unik kombination av nyckel/hänglås, där du lämnar över hänglåset till där du vill kunna logga in.

Arkitekturen bakom Passkeys

Passkeys möjliggörs av ett antal samverkande komponenter. Dessa är:

Authenticators
User Agents
Relying Party (RP)

Kommunikation och samarbete mellan dessa komponenter möjliggörs genom två öppna standarder, Web Authentication (WebAuthn) ¹ och Client to Authenticator Protocol (CTAP)² . Jag beskriver dessa i lite mer detalj längre ner.

Authenticators

Det finns två typer av authenticators, platform och roaming authenticators. Det är dessa systemkomponenter (kan vara mjukvara, eller hårdvara) som ansvarar för att skapa och lagra Passkeys samt möjliggöra autentisering genom Passkeys.

Platform Authenticators Platform authenticators är knutna till en specifik klientenhet exempelvis din mobiltelefon, eller laptop. En platformsspecifik authenticator kan göras tillgänglig för klienter (applikationer) som snurrar på din mobil eller laptop.

Roaming Authenticators Till skillnad från platform authenticators så innebär en roaming authenticator att den kan flyttas mellan olika klientenheter, och är således inte bunden till den specifika enheten. Detta är den vanligaste typen av authenticators och högst troligen den du själv kommer att använda.

Authenticators implementerar Client to Authenticator Protocol (CTAP, specifikt version 2.1).

User Agents (WebAuthen client)

Begreppet känner du säkert igen från webbläsarnas värld där user-agent förekommer väldigt ofta. Och en user-agent är helt enkelt den applikation som implementerar Web Authentication (WebAuthn) specifikationen/API:et tillsammans med klientenheten. Den vanligaste user-agenten är … webbläsaren.

Det är denna klient som ansvarar för att fixa fram input och output för underliggande authenticator anrop.

Relying Party (RP)

Detta är applikationerna som vill att du ska autentisera dig med hjälp av en Passkey, webb-applikationer som Google Mail, eller Proton Mail. En RP behöver bara kunna anropa (genom Javascript) ett antal funktioner i WebAuthn för att begära att Passkeys skapas eller hämtas ut från tillgängliga enheter.

Relying party lagrar den publika nyckeln som genererats vid registrering av ett konto.

Vad är egentligen en Authenticator?

Jo, visst, du såg att jag skrev Platform och Roaming Authenticators, men vad gör dom i praktiken kanske du fortfarande undrar? Authenticators är de enheter (mjukvara, eller hårdvara) som skapar, lagrar och i övrigt “hanterar” dina Passkeys.

Authenticators implementerar CTAP2 som du hittar under kapitel 6³. Det är i den specifikationen som gränssnittet för en authenticator beskrivs och definieras. När BitWarden, förhoppningsvis snart, får stöd för att hantera Passkeys är det just CTAP2 som de behöver implementera för att kunna erbjuda detta till “omvärlden”.

En authenticator implementation kan kontrollera om t.ex. användaren har aktiverat biometrisk inloggning (fingeravtryck), eller om det är PIN som används. Authenticator kan konfigureras till att acceptera vissa parametrar som avser om t.ex. PIN är nödvändigt för att kunna skapa Passkeys osv.

Det vi således sannolikt kommer att se är att allt fler lösenordshanterare kommer att erbjuda förmåga att hantera Passkeys. Exempelvis har Dashlane stöd för att generera Passkeys. ⁴ Android har stöd för att skapa Passkeys, men det är först nu i kommande version 14 som det kommer finnas stöd för att tredjeparts-authenticators kan hantera Passkeys.

Saknar din enhet stöd ?

Om du hamnar i den olyckliga situation att du behöver använda en Passkey-inloggning men enheten du använder saknar stöd för Passkey. Med lite tur kan du plugga in en USB-enhet, men då handlar det om att du behöver t.ex. en Yubikey för att kunna genomföra inloggningen.

Detta är också något som endast är en utmaning så här i övergången från att det finns utbrett stöd för Passkeys.

Du får helt enkelt se till att inte hamna i den situationen!

Vad hände med flerfaktors-autentisering?

MFA, OTP, 2FA och en rad andra uppsättningar av bokstäver och siffror kan med gott samvete betraktas som onödiga för de flesta inloggningar du kommer att göra. Men det är en bra backup-metod om du skulle förlora din mobiltelefon, få datorn stulen osv.

Men krasst så kan vi betrakta Passkeys som en kombination av flera olika typer av faktorer. Om vi går old school kan vi beskriva faktorer genom:

Något vi kan.
Något vi har.
Något vi är.

Ett lösenord faller inom något vi “kan”, och vanligtvis kombineras detta med något du har, eller i vissa fall något du är. Det är vad som ger oss flera faktorer, flerfaktors-autentisering. Men när det gäller Passkeys är det inte längre något vi riktigt behöver bry oss om längre. Åtminstone inte för de flesta typfallen för vad Passkeys är tänkta att ersätta: lösenorden.

Flerfaktor används i de allra flesta fall för att STÄRKA autentiseringen, bevisningen på att den du påstår dig vara är den du är.

Men det har ingenting med att göra VEM du är. Och det är vad som spelar roll i Enterprise-sammanhang och där kan det fortfarande finnas vissa krav på att du behöver både stärka din bevisning av identitet, men också att bevisningen sker på enheter som företaget VET tillhör dig.

Men för oss som privatpersoner på webben handlar det inte särskilt ofta om att du ska visa vem du är, bara att du har tillräckligt rimlig kontroll över den påstådda identiteten.

Så, jag skulle säga att Passkeys i stor utsträckning kan betraktas som ersättare för vanliga flerfaktors-appar som vi använder i det privata. Men när det gäller företag behöver vi ha en något annorlunda diskussion. Det går att lösa med bara Passkeys också, men som sagt, en annan diskussion.

Varför ska vi använda Passkeys?

Först och främst hjälper Passkeys användare komma bort från lösenord. Du kommer inte längre kunna tappa bort ett lösenord, glömma av lösenordet, eller låta det bli känt för att någon sajt du registrerat dig på blivit hackad. Det finns inga lösenord att prata om.

Om vi bara kan utgå ifrån att användare har en mobiltelefon, så fungerar det ganska bra med Passkeys. Däremot tror jag att de flesta “vanliga” användare som börjar med Passkeys kommer vilja kunna logga in från alla sina enheter, och då behöver vi ha synk på lagrade Passkeys.

Använder du ett Google Account så kommer nycklar synkas till molnet och alla dina enheter.

Hoten som försvinner, och kvarstår

Vi kommer slippa password breaches, eftersom det inte finns någon breach att tala om. Det enda en angripare kommer hitta är en publik nyckel, som är kopplad till den specifika sajten där den hittades och den går inte att använda till något.

Du kan inte heller luras att logga in mot fel sajt eftersom ett nyckelpar knyts till den URL som användes vid registrering, så det går inte heller att lura användare att autentisera sig mot fel domän. Då behöver det finnas sårbarheter i webbläsaren som får den att tro att den besöker rätt sajt, men i själva verket är uppkopplad mot en av angriparen kontrollerad sajt. Det är väsentligt mindre troligt att hända om vi jämför med att en användare tror att den är på rätt plats.

Det går inte heller att gissa lösenord, för det finns inga lösenord att gissa. Och när vi säger att Passkeys är phishing resistant betyder det att hur många fejkade inloggningssidor en hotaktör skapar så kommer han ändå aldrig att kunna lura av dig något lösenord, för du kommer inte kunna ange något på fel sajt. Och det skulle ändå inte spela någon roll, för de får ingenting de kan använda.

Synkar du Passkeys över t.ex. Gmail eller iCloud måste du också tänka på hur du skyddar de här kontona. För kommer jag åt ditt Google Account, har jag också dina Passkeys och kan få dessa synkade till mina enheter.

En angripare kan helt enkelt välja att lägga till en ny enhet på ditt konto, och till den kommer alla Passkeys synkas. Och därefter har en angripare möjlighet att autentisera sig mot alla de platser där du skapat Passkeys.

… kvarstår?

Det främsta hotet som kvarstår är att hotaktörer kan stjäla sessionskakor och helt enkelt kringgå autentiseringsförfarandet. Även om du gjort allting rätt, men lyckats få in skadlig kod på din dator kan en hotaktör stjäla aktiva sessioner. Alltså där du redan gjort autentiseringen. För någonstans i slutet av allt så får du en sessionskaka lagrad i din webbläsare som används för att upprätthålla en session.

Du kommer inte autentiseras vid varje anrop, och det är precis där som aktiva sessionskakor kommer in i bilden. Dessa kan stjälas från webbläsaren och är något som hotaktörer fokuserat i allt större utsträckning de senaste åren.

Öppna standarder på lite mer tekniskt djup

Passkeys är ett begrepp som först introducerades av Apple och senare anammades av övriga teknik världen. Men tekniskt sett är Passkeys många saker, men istället för att säga FIDO2 Discoverable Credentials, säger vi… Passkeys, det är alltså endast ett marknadsföringsbegrepp. Tekniskt finns det inte, titta in specifikationen för WebAuthn eller CTAP, det finns ingenting som heter Passkeys där.

Bakom Passkeys finns i huvudsak två öppna standarder, som gemensamt ofta kallas FIDO2. Web Authentication (WebAuthn), av W3C och Client to Authenticator Protocol 2 (CTAP2) av FIDO Alliance⁵, där FIDO står för Fast IDentity Online. FIDO Alliance är en sammanslutning av organisationer som gemensamt arbetar för autentiseringsstandarder med målsättning om att minska vårt beroende till lösenord, helst av allt helt ersätta dem.

Web Authentication (WebAuthn)

Detta är ett API som behöver implementeras av webbläsaren, eller klienten. Målet är att ge en applikation, genom Javascript, en möjlighet att interagera på ett säkert och standardiserat sätt med eventuella enheter som har eller ska registrera en Passkey.

Den viktigaste komponenten av detta API är PublicKeyCredential vilket är det nya gränssnittet som kan användas för att genom webbläsaren prata med authenticators.

Om du tar upp din webbläsare, och aktiverar developer mode och sedan skriver PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() kommer du att få svar på om huruvida den webbläsare du använder, och det operativssystem du använder har stöd för att skapa Passkeys.

Observera att om du använder Firefox kommer metoden isUserVerifying... inte att finnas.

Jag insåg när jag började skriva att jag inte kommer nå det tekniska djupet som är nödvändigt för att få kalla avsnittet “på lite mer tekniskt djup”, så jag skäms. Och kanske får lov att återkomma till detta vid ett senare tillfälle. Kanske implementera det via Python för att få kalla det tekniskt djup, eller?

Nyfiken på att prova? Då kan du besöka WebAuthn och du behöver inte oroa dig, även om detta var en phishing sajt skulle de inte kunna lura av dig något. Det enda dom skulle kunna göra är att be dig registrera dig, men några lösenord blir du inte av med. I värsta fall får dom ett hänglås av dig som inte går att

Client to Authenticator Protocol (CTAP)

… här var det nästan tomt. Jag vet ärligt talat inte vad jag från specifikationen ska lyfta fram. Det mest tekniskt väsentliga är ju att CTAP i huvudsak fokuserar på roaming authenticators.

Nästa steg, hur börjar du?

Om du använder Google-tjänster, eller Android, har du kanske redan en Passkey. Exempelvis innehåller Pixel 7 Pro redan Passkeys du kan använda. Och om du befinner dig i Apples ekosystem har du också möjlighet att börja använda Passkeys redan. Nycklar kommer att synkas mellan dina enheter från start.

Du kan även välja att skaffa hårdvaruenheter som kan lagras Passkeys, som t.ex. Yubikey. Notera dock att hårdvaruenheter vanligtvis är begränsade till hur många Passkeys de kan skapa och lagra.⁶

FIDO2 - the YubiKey 5 can hold up to 25 resident keys in its FIDO2 application.

Jag använder själv Yubikey för att skydda min lösenordshanterare, och min e-post (Proton). Och inloggningar för dessa vill jag skydda helt utan att det finns massa nycklar som flåsar runt hos leverantörerna (Google, Apple, Microsoft et al). Jag har fler än två nycklar kopplade till varje kritisk tjänst.

Och varför två? Well, förlorar du en av dessa fysiska nycklar har du en backup, utan denna har du ingenting. Så du behöver två, gärna egentligen tre som du förvarar på olika geografiska platser. Förhoppningsvis behöver du aldrig använda dem.

I skrivande stund har inte min föredragna lösenordshanterare (BitWarden) ännu stöd för att hantera Passkeys, men detta ska lanseras inom kort. När jag sedan behöver skapa nya PassKeys använder jag BitWarden för att generera dessa och koppla till sajter, och låter mjukvaran ta hand om lagringen.

Använder du e-post som backup, måste denna skyddas av flerfaktors-autentisering, gärna med fysiska Passkeys, precis så som jag gör med Yubikey.

Välkommen till en värld av lösenordsfria inloggningar. Jag hoppas att jag lyckats förklara något som fastnat :-)