1~
2A 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.
3~
4A 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.
5~
6## Mi történik valójában
7~
8A passkey a WebAuthn-n alapuló hitelesítő adat. Amikor a felhasználó létrehozza, az eszköz létrehoz egy kulcspárt:
9~
10- privát kulcs, amely a készüléken vagy a jelszókezelőben marad;
11- nyilvános kulcs, amelyet a szerver el tud menteni.
12~
13Bejelentkezé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.
14~
15Ez 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.
16~
17## A böngésző hídként működik
18~
19A böngészőben a két fő API a következő:
20~
21- `navigator.credentials.create()` passkey létrehozásához;
22- `navigator.credentials.get()`, hogy bejelentkezéskor használja.
23~
24De 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.
25~
26A kliens résznek szinte unalmasnak kell lennie:
27~
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30~
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34~
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41~
42Ha ú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.
43~
44## Mit kell menteni az adatbázisban
45~
46Nem kell megmenteni a fél világot. Általában elég:
47~
48- a hitelesítő okmány azonosítója;
49- nyilvános kulcs;
50- csatlakoztatott felhasználó;
51- bármely ellenőrzési számláló vagy metaadat;
52- szállítások, ha hasznosak az UX számára;
53- a felhasználó által választott név;
54- létrehozás dátuma és utolsó használat.
55~
56Egy minimális táblázat így nézhet ki:
57~
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69~
70Aztá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.
71~
72## Az UX többet számít, mint a demó
73~
74A passkey demója mindig gyönyörű: rákattint a Face ID gombra, máris belép. A tényleges termék bonyolultabb.
75~
76Valaki 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.
77~
78Ezért nem kezdeném azzal, hogy "mától nincs több jelszó mindenkinek". Én így kezdeném:
79~
801. passkey opcionális belső felhasználók számára;
812. javaslat létrehozására sikeres bejelentkezés után;
823. fiókoldal az átnevezéshez és eltávolításhoz passkey;
834. egyértelmű visszaesés;
845. fokozatos bevezetés a fő bejelentkezésben.
85~
86A 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”.
87~
88## Hibák, amelyeket elkerülnék
89~
90Ne okozzon kihívást az ügyfélnek. A kihívás a szerveren jön létre, és csak egyszer kell ellenőrizni.
91~
92Ne 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.
93~
94Ne 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”.
95~
96Ne kezelje a passkey-t pusztán előtérgombként. A gomb elrejtése nem jelent biztonságot: az igazi ellenőrzés szerveroldali.
97~
98## Passkey-első vagy passkey-barát?
99~
100Egy ú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.
101~
102Az 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.
103~
104## Következtetés
105~
106A 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.
107~
108De 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.
109~
110## Források
111~
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116~