1~
2Hasła to jedna z tych rzeczy, które znormalizowaliśmy tylko dlatego, że żyjemy z nimi od lat. Użytkownicy o nich zapominają, wykorzystują je ponownie, zapisują tam, gdzie nie powinni. Zespoły muszą zarządzać resetowaniem, zasadami, skrótami, wyciekami, phishingiem i wsparciem.
3~
4passkey nie czyni uwierzytelnienia doskonałym, ale usuwa ogromny problem: serwer nie musi już zachowywać tajemnicy udostępnianej użytkownikowi.
5~
6## Co się naprawdę dzieje
7~
8passkey to referencja oparta na WebAuthn. Gdy użytkownik go utworzy, urządzenie generuje parę kluczy:
9~
10- klucz prywatny, który pozostaje na urządzeniu lub w menedżerze haseł;
11- klucz publiczny, który serwer może zapisać.
12~
13Podczas logowania serwer nie pyta "podaj mi hasło". Wyślij losowe wyzwanie. Urządzenie podpisuje go kluczem prywatnym. Serwer weryfikuje podpis kluczem publicznym.
14~
15To właśnie jest fajne: jeśli baza danych zostanie skradziona, nie będzie w niej żadnych haseł, które można by złamać. A jeśli użytkownik trafi na fałszywą domenę, passkey nie będzie ważne dla tej domeny. To nie tylko wygoda, to konkretna ochrona przed phishingiem.
16~
17## Przeglądarka działa jak pomost
18~
19W przeglądarce dwa główne API to:
20~
21- `navigator.credentials.create()`, aby utworzyć passkey;
22- `navigator.credentials.get()`, aby użyć go podczas logowania.
23~
24Ale najważniejsza logika leży na serwerze. Serwer musi wygenerować wyzwanie, zapisać je tymczasowo, zweryfikować odpowiedź, sprawdzić źródło i Relying Party ID, a następnie utworzyć sesję.
25~
26Część klienta powinna być prawie nudna:
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~
42Jeśli zauważysz, że ręcznie wdrażasz szyfrowanie WebAuthn, przestań. Użyj solidnej biblioteki po stronie serwera. Błędy tutaj nie są „słodkimi błędami”, są to luki w uwierzytelnianiu.
43~
44## Co zapisać w bazie danych
45~
46Nie ma potrzeby ratowania połowy świata. Zwykle wystarczy:
47~
48- Identyfikator referencji;
49- klucz publiczny;
50- podłączony użytkownik;
51- dowolny licznik weryfikacyjny lub metadane;
52- transporty, jeśli są przydatne dla UX;
53- nazwa wybrana przez użytkownika;
54- data utworzenia i ostatniego użycia.
55~
56Minimalna tabela może wyglądać następująco:
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~
70Następnie dodałbym logi audytu i powiadomienia: jeśli ktoś utworzy nowe passkey na moim koncie, chcę o tym wiedzieć.
71~
72## UX jest ważniejszy niż demo
73~
74Demo passkey jest zawsze piękne: klikasz, Face ID i zaczynasz. Rzeczywisty produkt jest bardziej skomplikowany.
75~
76Ktoś zmienia telefon. Ktoś korzysta z zablokowanego komputera firmowego. Niektórzy ludzie nie rozumieją, dlaczego przeglądarka sugeruje passkey. Ktoś traci dostęp do swojego urządzenia.
77~
78Dlatego nie zaczynałbym od „od dzisiaj koniec z hasłami dla wszystkich”. Zacząłbym tak:
79~
801. passkey opcjonalne dla użytkowników wewnętrznych;
812. sugestia utworzenia go po udanym logowaniu;
823. strona konta do zmiany nazwy i usunięcia passkey;
834. wyraźne wycofanie;
845. stopniowe wdrażanie w głównym loginie.
85~
86Tekst w interfejsie powinien być prosty. „Użyj ekranu blokady swojego urządzenia” jest lepsze niż „uwierzytelnij się za pomocą danych uwierzytelniających rezydenta FIDO2”.
87~
88## Błędy, których chciałbym uniknąć
89~
90Nie generuj wyzwań dla klienta. Wyzwanie tworzone jest na serwerze i należy je zweryfikować tylko raz.
91~
92Nie ufaj tylko identyfikatorowi danych uwierzytelniających. Musisz zweryfikować podpis, wyzwanie, pochodzenie i Relying Party ID.
93~
94Nie usuwaj kopii zapasowych, zanim nie uzyskasz dobrego przepływu odzyskiwania. Bez hasła nie musi oznaczać, że „jeśli zgubisz telefon, przepadniesz na zawsze”.
95~
96Nie traktuj passkey jako przycisku czysto frontendowego. Ukrywanie przycisku nie zapewnia bezpieczeństwa: prawdziwa weryfikacja odbywa się po stronie serwera.
97~
98## Passkey-pierwszy czy passkey-przyjazny?
99~
100W przypadku nowego produktu możesz najpierw pomyśleć o passkey. W przypadku istniejącej aplikacji wolę przyjazną passkey: dodaj passkey jako zalecaną metodę, mierz sukcesy i problemy, a następnie spokojnie zmniejsz wagę hasła.
101~
102Idealna migracja nie jest odczuwalna. Użytkownik odkrywa, że ​​logowanie jest łatwiejsze, a nie, że firma zmieniła protokół uwierzytelniania.
103~
104## Wniosek
105~
106passkey są interesujące, ponieważ poprawiają jednocześnie bezpieczeństwo i UX, co jest rzadkością. To nie jest magiczna różdżka: odzyskiwanie, kompatybilność, wsparcie i wdrożenie muszą zostać dobrze zaprojektowane.
107~
108Ale podstawowa zmiana jest silna. Przestań prosić użytkowników o wymyślanie i chronienie tajemnic. Pozwalasz urządzeniu podpisać dowód kryptograficzny powiązany z Twoją domeną. Mniej pamięci ludzkiej, mniej phishingu, mniej resetowania haseł. Powiedziałbym, że warto je traktować poważnie.
109~
110## Źródła
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~