Hesla jsou jednou z věcí, které jsme normalizovali jen proto, že jsme s nimi léta žili. Uživatelé je zapomínají, znovu je používají, píší je tam, kde by neměli. Týmy musí spravovat resetování, zásady, hashe, úniky, phishing a podporu.
passkey nečiní autentizaci dokonalou, ale odstraňují obrovský problém: server již nemusí udržovat tajemství sdílené s uživatelem.
Co se skutečně stane
passkey je pověření založené na WebAuthn. Když jej uživatel vytvoří, zařízení vygeneruje pár klíčů:
- soukromý klíč, který zůstává v zařízení nebo ve správci hesel;
- veřejný klíč, který může server uložit.
Při přihlašování se server nevyptává "řekni mi heslo". Pošlete náhodnou výzvu. Zařízení jej podepíše soukromým klíčem. Server ověří podpis pomocí veřejného klíče.
To je ta hezká část: pokud je databáze ukradena, nejsou uvnitř žádná hesla k prolomení. A pokud uživatel skončí na falešné doméně, passkey pro tuto doménu neplatí. Není to jen pohodlí, je to konkrétní ochrana proti phishingu.
Prohlížeč funguje jako most
V prohlížeči jsou dvě hlavní API:
navigator.credentials.create()pro vytvoření passkey;navigator.credentials.get()pro použití během přihlášení.
Ale důležitá logika je na serveru. Server musí vygenerovat výzvu, dočasně ji uložit, ověřit odpověď, zkontrolovat zdroj a Relying Party ID, poté vytvořit relaci.
Klientská část by měla být téměř nudná:
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()), });
Pokud zjistíte, že implementujete šifrování WebAuthn ručně, přestaňte. Použijte robustní knihovnu na straně serveru. Chyby zde nejsou "roztomilé chyby", jsou to autentizační díry.
Co uložit do databáze
Není potřeba zachraňovat půlku světa. Obvykle stačí:
- ID pověření;
- veřejný klíč;
- připojený uživatel;
- jakékoli ověřovací počítadlo nebo metadata;
- transporty, pokud jsou užitečné pro UX;
- jméno zvolené uživatelem;
- datum vytvoření a poslední použití.
Minimální tabulka může vypadat takto:
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 );
Pak bych přidal protokoly auditu a upozornění: pokud někdo vytvoří nový passkey na mém účtu, chci o tom vědět.
UX je důležitější než demo
Demo passkey je vždy krásné: kliknete na Face ID a jste tam. Skutečný produkt je složitější.
Někdo změní telefon. Někdo používá zamčený firemní počítač. Někteří lidé nechápou, proč prohlížeč navrhuje passkey. Někdo ztratí přístup ke svému zařízení.
Proto bych nezačínal slovy „od dnešního dne už žádná hesla pro všechny“. Začal bych takto:
- passkey volitelné pro interní uživatele;
- návrh na vytvoření po úspěšném přihlášení;
- stránka účtu pro přejmenování a odstranění passkey;
- jasný záložní;
- postupné zavádění v hlavním přihlášení.
Text v rozhraní by měl být jednoduchý. „Použít zamykací obrazovku vašeho zařízení“ je lepší než „ověření pomocí rezidentního pověření FIDO2“.
Chyb, kterým bych se vyvaroval
Nevytvářejte na klienta výzvy. Výzva je vytvořena na serveru a musí být ověřena pouze jednou.
Nevěřte pouze identifikačnímu dokladu. Musíte ověřit podpis, výzvu, původ a Relying Party ID.
Neodstraňujte nouzová řešení, dokud nebudete mít dobrý tok obnovy. Passwordless se nemusí stát „pokud ztratíte telefon, jste navždy mimo“.
Nepovažujte passkey za čistě frontendové tlačítko. Skrytí tlačítka není zabezpečení: skutečné ověření je na straně serveru.
Passkey-první nebo passkey-přátelské?
U nového produktu si můžete myslet passkey-první. U stávající aplikace preferuji přátelské k passkey: přidejte passkey jako doporučenou metodu, měřte úspěch a problémy, pak klidně snižte váhu hesla.
Ideální migrace není cítit. Uživatel zjistí, že přihlášení je jednodušší, nikoli že společnost změnila svůj ověřovací protokol.
Závěr
passkey jsou zajímavé, protože zlepšují zabezpečení a UX současně, což je vzácné. Nejsou kouzelnou hůlkou: zbývá dobře navrhnout obnovu, kompatibilitu, podporu a zavádění.
Ale základní změna je silná. Přestaňte žádat uživatele, aby vymýšleli a chránili tajemství. Necháte zařízení podepsat kryptografický důkaz vázaný na vaši doménu. Méně lidské paměti, méně phishingu, méně resetování hesel. Řekl bych, že stojí za to je brát vážně.