Passkeys:Såfungerarlösenordetsersättareochvaradoptionenstår2025

Lösenord har varit webbens primära autentiseringsmetod sedan 90-talet. De fungerade hyfsat när en person hade tre konton. Nu har en genomsnittlig användare över hundra, och modellen har kollapsat. Passkeys är tekniken som ska ersätta dem, och den bygger på en fundamentalt annorlunda säkerhetsmodell: asymmetrisk kryptografi istället för delade hemligheter.

Den här artikeln går igenom hur passkeys fungerar tekniskt, varför de är motståndskraftiga mot phishing, var adoptionen står hösten 2025, och hur du implementerar dem på din egen sajt.

Varför lösenord är trasiga

Problemet med lösenord är inte att folk väljer dåliga lösenord (även om de gör det). Problemet är att hela modellen bygger på en delad hemlighet. Servern lagrar en representation av ditt lösenord, och du skickar lösenordet vid varje inloggning. Det skapar flera attackytor som inte går att eliminera oavsett hur komplext lösenordet är.

Credential stuffing i stor skala

Have I Been Pwned indexerar i skrivande stund över 15 miljarder läckta konton från kända dataintrång. I oktober 2025 lades ytterligare 183 miljoner unika e-postadresser till från en enda infostealer-logg ("Synthient Stealer Log"). 91 procent av dessa hade dykt upp i tidigare läckor, vilket visar hur samma credentials cirkulerar i åratal.

Angripare laddar ner dessa databaser och testar kombinationerna automatiskt mot andra tjänster. Det kallas credential stuffing, och det fungerar för att folk återanvänder lösenord. Undersökningar visar konsekvent att runt 80 till 85 procent av användare återanvänder lösenord på flera sajter. En analys av 19 miljarder läckta lösenord (april 2024 till april 2025) visade att 94 procent var återanvända eller duplicerade.

Phishing fungerar oavsett lösenordskomplexitet

Ett 32 tecken långt lösenord med specialtecken skyddar inte mot phishing. Om du skriver in det på en fejkad inloggningssida har angriparen det. Komplexitetskrav gör lösenord svårare att komma ihåg men inte säkrare mot social engineering.

SMS-OTP som andrafaktor: svagare än du tror

Många tjänster erbjuder SMS-engångskoder som tvåfaktorsautentisering. Det är bättre än bara lösenord, men inte mycket. Det finns tre etablerade attackvektorer:

SIM-swapping. Angriparen ringer din teleoperatör, utger sig för att vara du, och får ditt telefonnummer överfört till ett nytt SIM-kort. I Storbritannien rapporterade Cifas en ökning på 1 055 procent av obehöriga SIM-byten 2024 jämfört med 2023, med nästan 3 000 fall. FBI:s IC3 registrerade förluster på 26 miljoner dollar från SIM-swapping i USA under 2024.

SS7-attacker. SS7 (Signalling System No. 7) är protokollet som teleoperatörer använder för att dirigera SMS och samtal. Det designades på 1970-talet utan autentisering mellan noder. En angripare med tillgång till SS7-nätverket kan avlyssna SMS i transit. Det kräver resurser, men är dokumenterat i verkliga attacker.

Real-time phishing proxies. Verktyg som Evilginx2 (skrivet i Go, öppen källkod på GitHub) fungerar som en man-in-the-middle-proxy. Användaren besöker vad som ser ut som en legitim inloggningssida. Evilginx vidarebefordrar allt till den riktiga tjänsten i realtid. Användaren skriver in lösenord, får SMS-kod, skriver in den. Evilginx fångar sessionskakan efter att tvåfaktorsautentiseringen är klar. Angriparen har nu en autentiserad session. Det spelar ingen roll att du hade 2FA aktiverat. Den ryska APT-gruppen Star Blizzard (kopplad till FSB) har använt Evilginx i riktade phishing-kampanjer.

TOTP: bättre men fortfarande sårbart

Tidsbaserade engångskoder via appar som Google Authenticator eller Authy är säkrare än SMS. De är inte sårbara för SIM-swapping eller SS7-attacker. Men de är fortfarande phishable. En real-time phishing proxy fångar TOTP-koden precis som den fångar SMS-koder, eftersom användaren skriver in koden på angriparens sida som vidarebefordrar den till den riktiga tjänsten.

Hur passkeys fungerar tekniskt

Passkeys bygger på två standarder: WebAuthn (en W3C-standard) och FIDO2 (FIDO Alliance). WebAuthn definierar webbläsarens JavaScript-API. FIDO2 är det bredare ramverket som inkluderar WebAuthn plus CTAP2 (Client to Authenticator Protocol), som hanterar kommunikationen mellan webbläsaren och autentiseringsenheten (fingeravtrycksläsare, säkerhetsnyckel, etc).

Registrering: skapa en passkey

1. Du klickar "Skapa passkey" på en tjänst.
2. Tjänstens server genererar en challenge (en slumpmässig byte-sekvens) och skickar den till webbläsaren tillsammans med information om tjänsten (relying party ID, som är domännamnet) och användaren.
3. Webbläsaren anropar navigator.credentials.create() med dessa parametrar.
4. Operativsystemet visar en biometrisk prompt (Face ID, fingeravtryck, Windows Hello PIN).
5. Efter verifiering genererar enheten ett asymmetriskt nyckelpar (vanligtvis ECDSA med P-256). Den privata nyckeln lagras lokalt på enheten, skyddad av hårdvarans säkerhetsmodul (Secure Enclave på Apple, Titan M på Pixel, TPM på Windows).
6. Enheten signerar challenge:n med den privata nyckeln och skickar tillbaka den publika nyckeln plus signaturen till servern.
7. Servern verifierar signaturen och lagrar den publika nyckeln kopplad till användarkontot.

Inloggning: använda en passkey

1. Du klickar "Logga in" (eller väljer din passkey från autofill-menyn).
2. Servern genererar en ny challenge och skickar den till webbläsaren.
3. Webbläsaren anropar navigator.credentials.get().
4. Operativsystemet visar en biometrisk prompt.
5. Enheten signerar challenge:n med den privata nyckeln.
6. Servern verifierar signaturen med den lagrade publika nyckeln. Om den stämmer är du inloggad.

Varför phishing inte fungerar mot passkeys

Här är den avgörande skillnaden. När din enhet signerar en challenge, inkluderar den domännamnet (origin) i signaturen. Nyckeln är bunden till den specifika domänen, exempelvis example.com.

Om en angripare skapar en phishing-sida på examp1e.com och försöker initiera en passkey-inloggning, händer en av två saker: antingen hittar enheten ingen passkey för den domänen (eftersom nyckeln är bunden till example.com), eller så vägrar webbläsaren helt att använda nyckeln.

En real-time phishing proxy som Evilginx kan inte heller kringgå detta. Proxyn kan vidarebefordra HTML och JavaScript, men den kan inte ändra origin-bindningen. Signaturen som enheten skapar gäller för den domän som webbläsaren faktiskt befinner sig på, inte för den domän som proxyn vidarebefordrar trafik till.

Ingen delad hemlighet

Med lösenord lagrar servern en hash av ditt lösenord. Om servern hackas kan angriparen försöka knäcka hashen. Med passkeys lagrar servern bara din publika nyckel. Den publika nyckeln kan inte användas för att logga in. Du behöver den privata nyckeln för att signera en challenge, och den lämnar aldrig din enhet (eller ditt krypterade moln, om du använder synkroniserade passkeys).

Det betyder att ett dataintrång mot tjänsten inte ger angriparen något användbart för autentisering.

Synkroniserade passkeys vs device-bound passkeys

Det finns två kategorier av passkeys, och skillnaden har betydande säkerhetsimplikationer.

Device-bound passkeys

Med device-bound passkeys lämnar den privata nyckeln aldrig den fysiska enheten. Exempel: FIDO2-säkerhetsnycklar som YubiKey 5-serien eller Google Titan Security Key. Nyckeln genereras i en säker hårdvarumodul och kan inte exporteras.

Fördelen: maximal säkerhet. Ingen molntjänst kan komprometteras för att komma åt nyckeln.

Nackdelen: om du tappar enheten är nyckeln borta. Du behöver backup-nycklar eller andra recovery-metoder.

Synkroniserade passkeys

Med synkroniserade passkeys krypteras den privata nyckeln och synkroniseras via en molntjänst. Det är detta som Apple, Google och lösenordshanterare som 1Password och Bitwarden implementerar.

Apple synkroniserar passkeys via iCloud Keychain. Nyckelmaterialet är end-to-end-krypterat, vilket innebär att Apple inte kan läsa dina privata nycklar. Synkroniseringen sker till alla enheter med samma Apple ID. Stöd sedan iOS 16 (september 2022) och macOS Ventura (oktober 2022).

Google synkroniserar passkeys via Google Password Manager. Nyckelmaterialet krypteras med enhetens skärmlåskod. Sedan Android 14 (oktober 2023) stöds passkeys som en förstklassig autentiseringsmetod. Chrome 118+ har fullt stöd.

Tredjepartshanterare. 1Password, Bitwarden, Dashlane och andra lösenordshanterare kan lagra och synkronisera passkeys. Det ger plattformsoberoende synkronisering: en passkey skapad i 1Password på macOS fungerar i 1Password på Windows och Android.

Avvägningen

Synkroniserade passkeys gör att du inte förlorar åtkomst om du tappar en enhet. Du loggar in på en ny enhet med ditt Apple ID, Google-konto eller lösenordshanterare och har dina passkeys tillgängliga.

Priset är att din attack-yta utökas. Om någon komprometterar ditt iCloud-konto (med Advanced Data Protection avstängt) eller ditt Google-konto, kan de potentiellt komma åt dina synkroniserade passkeys. I praktiken kräver det att angriparen tar sig förbi kontots egna skyddsmekanismer, inklusive tvåfaktorsautentisering på själva molnkontot.

Cross-platform-användning

Passkeys som skapats på en iPhone kan användas på en Windows-dator. Flödet fungerar så här: Windows-datorn visar en QR-kod. Du skannar den med din iPhone. En Bluetooth-koppling verifierar att båda enheterna befinner sig fysiskt nära varandra (för att förhindra remote relay-attacker). Du autentiserar med Face ID eller fingeravtryck på telefonen. Inloggningen slutförs på datorn.

Det fungerar även i omvänd riktning: passkeys på en Android-telefon kan användas via QR-kod på en Mac.

UX-flödet ur användarens perspektiv

En vanlig kritik mot säkerhetstekniker är att de är krångliga. Passkeys är ovanliga i att de faktiskt förbättrar användarupplevelsen jämfört med det de ersätter.

Registrering

1. Du besöker en tjänst och klickar "Skapa passkey" (eller "Lägg till passkey" i kontoinställningar).
2. En systemdialog dyker upp: "Vill du spara en passkey för example.com?"
3. Du verifierar med biometri (fingeravtryck, ansiktsigenkänning) eller enhetens PIN-kod.
4. Klart. Ingen e-postverifiering, inget lösenord att hitta på, inga krav på versaler och specialtecken.

Inloggning

1. Du besöker tjänstens inloggningssida.
2. Du klickar "Logga in med passkey" eller väljer din passkey från autofill-menyn.
3. Biometrisk verifiering.
4. Inloggad.

Enligt FIDO Alliance uppnår passkey-inloggningar en lyckad-autentisering-frekvens på 93 procent, jämfört med 63 procent för traditionella lösenordsbaserade inloggningar. Skillnaden beror på att det inte finns något att skriva fel, glömma eller kopiera från en annan app.

Conditional UI: passkeys i autofill-menyn

Den smidigaste implementationen är Conditional UI (WebAuthn Conditional Mediation). Istället för en separat "Logga in med passkey"-knapp dyker passkeys upp direkt i webbläsarens autofill-meny, precis som sparade lösenord gör idag. Användaren klickar på användarnamn-fältet, ser sin passkey i dropdown-listan, väljer den, verifierar med biometri.

Det kräver att HTML-formuläret har attributet autocomplete="username webauthn" på användarnamn-fältet, och att JavaScript-koden anropar navigator.credentials.get() med mediation: "conditional". Webbläsaren väntar i bakgrunden tills användaren interagerar med autofill-menyn.

Chrome, Safari och Edge stöder Conditional UI. Firefox har grundläggande passkey-stöd men Conditional UI-implementationen ligger efter de andra webbläsarna.

Var adoptionen står hösten 2025

Passkeys har gått från experimentell teknik till mainstream på tre år. Här är nuläget.

Plattformsstöd

Apple har haft passkey-stöd sedan iOS 16 (september 2022) och macOS Ventura (oktober 2022). Passkeys synkroniseras via iCloud Keychain och fungerar i Safari och alla appar som använder ASAuthorizationController. Från iOS 17 stöds även passkeys i autofill i tredjepartsappar.

Google lanserade passkey-stöd i Android 14 (oktober 2023) och Chrome 118+. Passkeys är nu standardförslaget vid inloggning på Google-konton. Google uppgav i maj 2024 att över 400 miljoner Google-konton hade använt passkeys.

Microsoft har integrerat passkeys med Windows Hello i Windows 11. Edge har fullt stöd. I maj 2025 meddelade Microsoft att nya Microsoft-konton skapas utan lösenord som standard, med passkeys som primär autentiseringsmetod.

Tjänster med passkey-stöd

Listan växer stadigt. Några av de större tjänsterna: Google, Apple, Microsoft, Amazon, GitHub, PayPal, Shopify, WhatsApp, X (tidigare Twitter), Adobe, Nintendo, TikTok, LinkedIn, Uber, eBay, Yahoo, Coinbase, Robinhood, Kayak, DocuSign.

Passkeys.directory (drivet av Dashlane) och passkeys.com listar hundratals tjänster med stöd, inklusive detaljerad information om vilken typ av passkey-implementation varje tjänst har.

Siffror på adoption

Enligt FIDO Alliances Passkey Index från oktober 2025: 48 procent av världens 100 största webbplatser stöder passkeys, mer än en fördubbling sedan 2022. Över 15 miljarder online-konton kan använda passkeys. Över tre miljarder passkeys är i aktiv användning. 75 procent av konsumenter känner till passkeys, och 69 procent har minst en passkey.

I företagssegmentet uppger 87 procent av tillfrågade organisationer att de har implementerat eller håller på att implementera passkeys, en ökning med 14 procentenheter jämfört med 2022.

Implementera passkeys på din sajt

Om du bygger en webbapplikation och vill erbjuda passkeys har du två huvudvägar: implementera WebAuthn-API:et direkt eller använda en hosted auth-tjänst som hanterar det åt dig.

Direkt implementation med WebAuthn API

WebAuthn-API:et i webbläsaren består av två huvudfunktioner:

navigator.credentials.create() för registrering. Du skickar med ett PublicKeyCredentialCreationOptions-objekt som innehåller:

• challenge: en kryptografiskt slumpmässig byte-sekvens från din server
• rp: relying party-information (ditt domännamn och visningsnamn)
• user: användarens ID, namn och visningsnamn
• pubKeyCredParams: vilka kryptografiska algoritmer du stöder (ES256 är standard)
• authenticatorSelection: om du vill kräva plattformsautentisering (biometri) eller tillåta roaming-nycklar (USB-nycklar)
• timeout: hur länge ceremonin får ta

navigator.credentials.get() för inloggning. Du skickar med ett PublicKeyCredentialRequestOptions-objekt som innehåller:

• challenge: ny slumpmässig byte-sekvens
• rpId: ditt domännamn
• allowCredentials: lista över credential-ID:n för användaren (kan utelämnas för discoverable credentials)
• timeout: tidsgräns

Server-side libraries

Du behöver server-side-logik för att generera challenges, verifiera signaturer och lagra publika nycklar. Det finns mogna bibliotek för de flesta språk:

• Node.js: SimpleWebAuthn (@simplewebauthn/server och @simplewebauthn/browser). Väldokumenterat, aktivt underhållet, TypeScript-native.
• Python: py_webauthn. Stöder registrering och autentisering med minimal konfiguration.
• Ruby: webauthn-ruby. Kan integreras med Devise via devise-passkeys-paketet.
• Rust: webauthn-rs. Prestandaorienterat bibliotek med strikt typning.
• Go: go-webauthn. Stöder FIDO2 och U2F.
• Java: java-webauthn-server (från Yubico).
• PHP: web-auth/webauthn-lib.

Hosted auth-tjänster med passkey-stöd

Om du inte vill hantera WebAuthn-logik själv finns det tjänster som abstraherar bort det:

• Auth0 (Okta): passkey-stöd i Universal Login. Du aktiverar det i dashboarden.
• Clerk: inbyggt passkey-stöd med färdiga React-komponenter.
• Passage (by 1Password): specialiserad passkey-as-a-service. Erbjuder färdiga UI-element och backend-logik.
• Corbado: fokuserat på passkey-implementation med analytics och fallback-hantering.
• Hanko: open source passkey-backend med färdiga web components.

Migrationsstrategi: från lösenord till passkeys

En abrupt övergång fungerar inte. Användare har olika enheter, olika webbläsare, och olika komfortnivåer med ny teknik. En rimlig migrationsplan:

Fas 1: Erbjud passkeys som alternativ. Användare med lösenord kan fortsätta logga in som vanligt. I kontoinställningar finns en option att skapa en passkey. Vid inloggning visas passkeys i autofill-menyn via Conditional UI om användaren har en.

Fas 2: Uppmuntra passkeys aktivt. Efter lyckad lösenordsinloggning, visa en prompt: "Vill du skapa en passkey för snabbare inloggning nästa gång?" Googles data visar att den här typen av nudging ökar adoptionen markant.

Fas 3: Gör passkeys till standardmetoden. Visa passkey-inloggning som det första alternativet. Lösenord finns kvar som fallback via en "Logga in med lösenord"-länk.

Fas 4 (långsiktigt): Valfritt ta bort lösenord. Låt användare som har registrerat passkeys och verifierat att de fungerar välja att ta bort sitt lösenord helt. Det är den approach som Microsoft valt för nya konton.

Account recovery

Recovery-flödet är den svåraste delen av passkey-implementation. Om en användare tappar alla sina enheter och inte har tillgång till sin molnbackup, hur får de tillbaka åtkomsten?

Alternativ som fungerar i praktiken:

• Synkroniserade passkeys via moln (iCloud Keychain, Google Password Manager, 1Password). Om du byter telefon synkas dina passkeys automatiskt till den nya.
• Flera registrerade passkeys. Uppmuntra användare att registrera passkeys på flera enheter (telefon plus laptop, eller en fysisk säkerhetsnyckel som backup).
• Recovery codes. Engångskoder som användaren kan skriva ut och förvara säkert. Samma koncept som GitHub och andra använder idag.
• Identitetsverifiering. Vid kontaktlös recovery kan du verifiera identiteten via en kombination av e-post, telefon och en manuell process.

Varför "lösenord plus SMS-OTP" är svagare än folk tror

Det finns en utbredd uppfattning att lösenord plus SMS-tvåfaktor ger god säkerhet. Det var sant 2015. Det är inte sant 2025.

Real-time phishing proxies

Evilginx2 är det mest kända verktyget, men det finns flera. Modlishka, EvilnoVNC och Muraena fungerar på liknande sätt. De sätter upp en reverse proxy framför den riktiga tjänsten. Användaren ser ett giltigt TLS-certifikat (angriparen får ett via Let's Encrypt för sin domän), en inloggningssida som ser identisk ut, och det hela beter sig exakt som den riktiga tjänsten, för det är den riktiga tjänsten som körs bakom proxyn.

Flödet: användaren skriver in lösenord, proxyn vidarebefordrar det. Tjänsten skickar SMS-kod. Användaren skriver in den. Proxyn vidarebefordrar den. Tjänsten skapar en autentiserad session. Proxyn fångar session-cookien. Angriparen kopierar cookien till sin egen webbläsare. Klart.

Det skyddar varken lösenordet, SMS-koden eller sessionen.

SIM-swapping skalas via social engineering

En SIM-swap kräver att angriparen övertygar en kundtjänstmedarbetare hos teleoperatören att överföra numret. Det låter svårt, men i praktiken har det skalats via mutor till butiksanställda, social engineering med läckta personuppgifter, och i vissa fall automatiserade verktyg. I mars 2025 dömdes T-Mobile att betala 33 miljoner dollar i skiljedom efter att en enda SIM-swap möjliggjorde stöld av kryptovaluta.

SS7 är fortfarande relevant

SS7-attacker är dyrare och svårare att utföra, men de förekommer. De kräver tillgång till en SS7-nod, vilket kan köpas via korrupta teleoperatörer i vissa regioner. SMS-innehåll avlyssnas på nätverksnivå utan att offret märker något.

Varför passkeys är immuna

Passkeys är motståndskraftiga mot alla tre attackerna av samma anledning: det finns ingen delad hemlighet att fånga.

Vid en phishing-proxy-attack: enheten signerar challenge:n med origin-bindning till den riktiga domänen. Proxyn kan inte ändra origin i signaturen. Servern avvisar signaturer från fel domän.

Vid SIM-swapping: irrelevant. Passkeys involverar inte telefonnummer eller SMS.

Vid SS7-attacker: irrelevant av samma anledning.

Den enda attackvektorn mot synkroniserade passkeys som kvarstår är kompromittering av molnkontot (Apple ID, Google-konto) som synkroniserar nycklarna. Det är en reell risk, men det är en attack mot ett enskilt konto med starka skyddsmekanismer, inte en skalbar attack som kan riktas mot miljontals användare samtidigt.

Tekniska detaljer som är värda att känna till

Resident keys vs server-side credentials

En passkey kan vara "discoverable" (resident key) eller "server-side". Med discoverable credentials lagras credential-informationen på enheten, och användaren behöver inte uppge ett användarnamn, enheten vet vilka passkeys som finns för vilken domän. Det är det som gör autofill-flödet möjligt.

Med server-side credentials lagras credential-ID:t på servern och skickas som allowCredentials i authentication-requesten. Användaren måste uppge sitt användarnamn först. Det är det äldre FIDO2-flödet och används mest med fysiska säkerhetsnycklar.

De flesta moderna passkey-implementationer använder discoverable credentials.

Attestation

Vid registrering kan servern begära attestation, som bevisar att passkeyn skapades av en specifik typ av autentisering (exempelvis en YubiKey 5 med firmware version X). I de flesta konsumentflöden skippar man attestation (attestation: "none") eftersom det inte är relevant. I enterprise-miljöer kan det användas för att säkerställa att bara godkända enheter registreras.

PRF-extension (Pseudo-Random Function)

WebAuthn PRF-extension låter en passkey generera en deterministisk nyckel baserad på den privata nyckeln. Det öppnar för att använda passkeys som grund för krypteringsnycklar, exempelvis för end-to-end-krypterade anteckningar eller filer. Bitwarden använder PRF-extension för att låta användare låsa upp sitt valv med en passkey.

Vad som återstår

Passkeys löser phishing, credential stuffing och problemet med delade hemligheter. Det som återstår att lösa handlar mest om praktiska frågor:

Portabilitet mellan ekosystem. FIDO Alliance publicerade i oktober 2024 ett utkast till Credential Exchange Protocol (CXP) och Credential Exchange Format (CXF), som ska standardisera export och import av passkeys mellan olika plattformar och lösenordshanterare. Det är ännu inte färdigställt.

Enterprise-specifika behov. Organisationer vill ha policy-kontroll: vilka autentiserare godkänns, ska synkronisering tillåtas, hur hanteras offboarding. Microsoft Entra ID och Okta arbetar på finare granularitet här.

Recovery-flöden. Det finns ingen universell standard för recovery. Varje tjänst hanterar det på sitt sätt. Det leder till inkonsekvens och ibland osäkra fallbacks (som att skicka en magic link till e-post, vilket i praktiken reducerar säkerheten till e-postkontots skydd).

Trots dessa utmaningar har passkeys nått en punkt där stödet finns i alla stora operativsystem, alla stora webbläsare, och en kritisk massa av tjänster. Om du bygger en ny autentisering idag finns det ingen anledning att inte inkludera passkeys som ett alternativ.