Parolele sunt unul dintre acele lucruri pe care le-am normalizat doar pentru că am trăit cu ele de ani de zile. Utilizatorii le uită, le refolosesc, le scriu acolo unde nu ar trebui. Echipele trebuie să gestioneze resetările, politicile, hashurile, scurgerile, phishingul și asistența.
passkey nu fac autentificarea perfectă, dar înlătură o problemă uriașă: serverul nu mai trebuie să păstreze un secret partajat cu utilizatorul.
Ce se întâmplă cu adevărat
Un passkey este o acreditare bazată pe WebAuthn. Când utilizatorul îl creează, dispozitivul generează o pereche de chei:
- o cheie privată, care rămâne pe dispozitiv sau în managerul de parole;
- o cheie publică, pe care serverul o poate salva.
Când vă autentificați, serverul nu vă întreabă „spuneți-mi parola”. Trimite o provocare aleatorie. Dispozitivul îl semnează cu cheia privată. Serverul verifică semnătura cu cheia publică.
Aceasta este partea frumoasă: dacă baza de date este furată, nu există parole de spart. Și dacă un utilizator ajunge pe un domeniu fals, passkey nu este valabil pentru acel domeniu. Nu este doar comoditate, este o protecție concretă împotriva phishingului.
Browserul acționează ca o punte
În browser, cele două API principale sunt:
navigator.credentials.create()pentru a crea un passkey;navigator.credentials.get()pentru a-l folosi în timpul conectării.
Dar logica importantă este pe server. Serverul trebuie să genereze provocarea, să o salveze temporar, să verifice răspunsul, să verifice sursa și Relying Party ID, apoi să creeze sesiunea.
Partea client ar trebui să fie aproape plictisitoare:
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()), });
Dacă implementați manual criptarea WebAuthn, opriți-vă. Utilizați o bibliotecă robustă pe partea de server. Erorile de aici nu sunt „bucuri drăguțe”, ci găuri de autentificare.
Ce să salvezi în baza de date
Nu este nevoie să salvezi jumătate din lume. De obicei suficient:
- ID-ul acreditării;
- cheie publică;
- utilizator conectat;
- orice contor de verificare sau metadate;
- transporturi, dacă sunt utile pentru UX;
- numele ales de utilizator;
- data creării și ultima utilizare.
Un tabel minim ar putea arăta astfel:
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 );
Apoi aș adăuga jurnale de audit și notificări: dacă cineva creează un nou passkey pe contul meu, vreau să știu despre asta.
UX contează mai mult decât demonstrația
Demo-ul unui passkey este întotdeauna frumos: dați clic, Face ID, sunteți. Produsul propriu-zis este mai complicat.
Cineva își schimbă telefonul. Cineva folosește un computer al companiei blocat. Unii oameni nu înțeleg de ce browserul sugerează un passkey. Cineva pierde accesul la dispozitivul său.
Acesta este motivul pentru care nu aș începe cu „de azi nu mai sunt parole pentru toată lumea”. as incepe asa:
- passkey opțional pentru utilizatorii interni;
- sugestie de a crea unul după o conectare cu succes;
- pagina de cont pentru a redenumi și a elimina passkey;
- alternativă clară;
- lansare treptată în login principal.
Textul din interfață ar trebui să fie simplu. „Utilizați ecranul de blocare al dispozitivului” este mai bine decât „autentificați-vă cu o autentificare rezidentă FIDO2”.
Greșeli pe care le-aș evita
Nu generați provocări clientului. Provocarea este creată pe server și trebuie verificată o singură dată.
Nu aveți încredere doar în ID-ul acreditării. Trebuie să verificați semnătura, provocarea, originea și Relying Party ID.
Nu ștergeți fallback-urile înainte de a avea un flux bun de recuperare. Fără parolă nu trebuie să devină „dacă îți pierzi telefonul, ești afară pentru totdeauna”.
Nu tratați passkey ca pe un buton pur frontal. Ascunderea unui buton nu este securitate: verificarea reală este pe partea serverului.
Passkey-primul sau passkey prietenos?
Pentru un produs nou te poți gândi la passkey-întâi. Pentru o aplicație existentă prefer passkey: adăugați passkey ca metodă recomandată, măsurați succesul și problemele, apoi reduceți cu calm greutatea parolei.
Migrația ideală nu se simte. Utilizatorul descoperă că autentificarea este mai ușoară, nu că compania și-a schimbat protocolul de autentificare.
Concluzie
passkey sunt interesante pentru că îmbunătățesc securitatea și UX în același timp, ceea ce este rar. Nu sunt o baghetă magică: recuperarea, compatibilitatea, suportul și lansarea rămân bine concepute.
Dar schimbarea de bază este puternică. Nu le mai cere utilizatorilor să inventeze și să protejeze secretele. Permiteți dispozitivului să semneze o dovadă criptografică legată de domeniul dvs. Mai puțină memorie umană, mai puțin phishing, mai puține resetări de parole. Aș spune că merită luate în serios.