Passkey és WebAuthn: bejelentkezés jelszó nélkül, varázslat nélkül
· 4 min read · Filippo Spinella · Security, WebAuthn, Authentication, Web Development
A jelszavak egyike azon dolgoknak, amelyeket csak azért normalizáltunk, mert évek óta együtt élünk velük. A felhasználók elfelejtik, újra felhasználják, oda írják, ahol nem kellene. A csapatoknak kezelniük kell a visszaállításokat, a házirendeket, a kivonatokat, a szivárgásokat, az adathalászatot és a támogatást.
A passkey nem teszi tökéletessé a hitelesítést, de elhárítanak egy hatalmas problémát: a szervernek nem kell többé megőriznie a felhasználóval megosztott titkot.
Mi történik valójában
A passkey a WebAuthn-n alapuló hitelesítő adat. Amikor a felhasználó létrehozza, az eszköz létrehoz egy kulcspárt:
- privát kulcs, amely a készüléken vagy a jelszókezelőben marad;
- nyilvános kulcs, amelyet a szerver el tud menteni.
Bejelentkezéskor a szerver nem kéri a "mondd meg a jelszót". Küldj egy véletlenszerű kihívást. A készülék a privát kulccsal írja alá. A szerver a nyilvános kulccsal ellenőrzi az aláírást.
Ez a szép rész: ha az adatbázist ellopják, nincsenek benne feltörhető jelszavak. És ha egy felhasználó egy hamis domainre kerül, a passkey nem érvényes az adott tartományra. Ez nem csak kényelem, hanem konkrét védelem az adathalászat ellen.
A böngésző hídként működik
A böngészőben a két fő API a következő:
navigator.credentials.create()passkey létrehozásához;navigator.credentials.get(), hogy bejelentkezéskor használja.
De a fontos logika a szerveren van. A szervernek generálnia kell a kihívást, ideiglenesen el kell mentenie, ellenőriznie kell a választ, ellenőriznie kell a forrást és a Relying Party ID-t, majd létre kell hoznia a munkamenetet.
A kliens résznek szinte unalmasnak kell lennie:
const options = await fetch('/api/passkeys/login/options').then((r) => r.json()); const credential = await navigator.credentials.get({ publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options), }); await fetch('/api/passkeys/login/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(credential?.toJSON()), });
Ha úgy találja, hogy kézzel hajtja végre az WebAuthn titkosítást, hagyja abba. Használjon robusztus szerveroldali könyvtárat. A hibák itt nem "cuki hibák", hanem hitelesítési lyukak.
Mit kell menteni az adatbázisban
Nem kell megmenteni a fél világot. Általában elég:
- a hitelesítő okmány azonosítója;
- nyilvános kulcs;
- csatlakoztatott felhasználó;
- bármely ellenőrzési számláló vagy metaadat;
- szállítások, ha hasznosak az UX számára;
- a felhasználó által választott név;
- létrehozás dátuma és utolsó használat.
Egy minimális táblázat így nézhet ki:
create table passkey_credentials ( id uuid primary key default gen_random_uuid(), user_id uuid not null references users(id), credential_id text not null unique, public_key text not null, name text, created_at timestamptz not null default now(), last_used_at timestamptz );
Aztán hozzáadnám az ellenőrzési naplókat és értesítéseket: ha valaki új passkey-t hoz létre a fiókomban, tudni szeretnék róla.
Az UX többet számít, mint a demó
A passkey demója mindig gyönyörű: rákattint a Face ID gombra, máris belép. A tényleges termék bonyolultabb.
Valaki lecseréli a telefonját. Valaki zárolt céges számítógépet használ. Vannak, akik nem értik, hogy a böngésző miért javasolja a passkey-t. Valaki elveszíti hozzáférését az eszközéhez.
Ezért nem kezdeném azzal, hogy "mától nincs több jelszó mindenkinek". Én így kezdeném:
- passkey opcionális belső felhasználók számára;
- javaslat létrehozására sikeres bejelentkezés után;
- fiókoldal az átnevezéshez és eltávolításhoz passkey;
- egyértelmű visszaesés;
- fokozatos bevezetés a fő bejelentkezésben.
A felület szövegének egyszerűnek kell lennie. A „Az eszköz zárolási képernyőjének használata” jobb, mint a „hitelesítés FIDO2 lakos hitelesítő adataival”.
Hibák, amelyeket elkerülnék
Ne okozzon kihívást az ügyfélnek. A kihívás a szerveren jön létre, és csak egyszer kell ellenőrizni.
Ne csak a hitelesítő azonosítóban bízzon. Ellenőriznie kell az aláírást, a kihívást, a származást és az Relying Party ID-t.
Ne törölje a tartalékokat a megfelelő helyreállítási folyamat előtt. A jelszó nélkülinek nem kell „ha elveszti a telefonját, akkor örökre kint lesz”.
Ne kezelje a passkey-t pusztán előtérgombként. A gomb elrejtése nem jelent biztonságot: az igazi ellenőrzés szerveroldali.
Passkey-első vagy passkey-barát?
Egy új terméknél először a passkey-re gondolhat. Egy meglévő alkalmazásnál a passkey-barát megoldást részesítem előnyben: adjuk hozzá a passkey-t ajánlott módszerként, mérjük fel a sikert és a problémákat, majd nyugodtan csökkentsük a jelszó súlyát.
Az ideális migráció nem érezhető. A felhasználó rájön, hogy a bejelentkezés egyszerűbb, nem pedig azt, hogy a vállalat megváltoztatta a hitelesítési protokollját.
Következtetés
A passkey érdekesek, mert egyszerre javítják a biztonságot és a felhasználói élményt, ami ritka. Nem varázspálca: a helyreállítást, a kompatibilitást, a támogatást és a bevezetést még jól meg kell tervezni.
De az alapvető változás erős. Ne kérd fel a felhasználókat a titkok kitalálására és védelmére. Hagyja, hogy az eszköz aláírjon egy, a domainjéhez kötött titkosítási bizonyítékot. Kevesebb emberi memória, kevesebb adathalászat, kevesebb jelszó-visszaállítás. Azt mondanám, hogy érdemes komolyan venni őket.