WebAuthn delimitează credențialele; produsul decide recuperarea

Un produs poate verifica o credențială puternică și poate avea totuși un răspuns neclar când titularul pierde toate mijloacele de a o folosi. WebAuthn Level 3 oferă o graniță definită pentru autentificare. Echipele de produs ar trebui să folosească această graniță pentru a proiecta explicit recuperarea, inclusiv dovezile acceptate când autentificarea obișnuită nu este disponibilă. Altfel, calea cel mai puțin înțeleasă poate ajunge să decidă cine controlează contul.

Privit din noiembrie, evenimentul istoric este precis. Anunțul W3C din 25 august 2026 identifică Level 3 drept Recommendation. Recomandarea datată precizează ea însăși statutul și data. Este o dovadă despre maturitatea standardului. Nu dovedește că fiecare navigator și fiecare autentificator oferea toate funcțiile Level 3 în acea zi.

Porniți de la ce dovedește o credențială

Recomandarea descrie credențiale limitate la o entitate WebAuthn Relying Party, aplicația care le folosește. Secțiunea 7.2 definește verificarea răspunsului de autentificare, inclusiv asocierea cu contul, provocarea, originea așteptată, verificarea RP ID hash și a semnăturii. Aceste verificări dau sens unei anumite proceduri de autentificare. Limitele lor ar trebui să rămână vizibile când produsul descrie ce dovedește conectarea.

De aici rezultă o decizie de produs: acceptarea unui răspuns de autentificare și stabilirea persoanei care poate înlocui o credențială inaccesibilă sunt operații diferite. Prima poate urma procedura de verificare. A doua are nevoie de o politică pentru dovezi din afara acelei autentificări reușite. Faptul că ambele permit accesul la cont nu face dovezile interschimbabile. Recuperarea cere o explicație proprie despre cine acționează și ce autoritate permite schimbarea.

Explicația contează chiar dacă ecranul de conectare este simplu. Un client poate considera recuperarea telefonului, recuperarea contului furnizorului de credențiale și recuperarea contului aplicației drept un singur proces. Echipa de produs ar trebui să le deosebească înainte de a scrie instrucțiuni. Altfel, un mesaj de asistență poate promite un acces pe care dovezile disponibile nu îl justifică sau poate trimite un utilizator legitim pe o cale care nu poate încheia operația dorită.

Descrieți separat pierderea tuturor mijloacelor

O analiză utilă a proiectării pornește de la o situație obișnuită și elimină treptat presupunerile. Examinați mai întâi accesul printr-un autentificator rămas disponibil. Apoi luați cazul unui dispozitiv pierdut, cu o credențială sincronizată utilizabilă în altă parte. În cele din urmă, analizați cazul în care toate autentificatoarele utilizabile sunt inaccesibile. Sunt situații ipotetice de analiză, nu conturi testate aici. Ultimul caz merită o decizie explicită, în locul unei instrucțiuni care presupune că utilizatorul se mai poate autentifica.

Pentru acel caz, identificați ce ar putea stabili aplicația prin procesul de recuperare ales. O adresă înregistrată, o conversație cu asistența și un răspuns de autentificare verificat reprezintă dovezi diferite. Dacă o anumită combinație este suficientă depinde de consecințele accesului la cont și de politica produsului. Articolul nu prescrie o singură procedură de verificare a identității pentru toate aplicațiile. Recomandă luarea și explicarea deciziei înainte ca asistența să fie nevoită să improvizeze.

Includeți revenirea la folosirea obișnuită. Dacă recuperarea permite asocierea unei credențiale noi cu un cont, produsul are de decis și ce se întâmplă cu accesul disponibil anterior, precum și cum află titularul despre schimbare. Acestea sunt întrebări despre ciclul de viață al contului. O nouă autentificare reușită nu stabilește singură dacă accesul anterior ar trebui să rămână valid sau ce ar trebui să comunice asistența despre el.

Sincronizarea oferă un contraargument important

Credențialele sincronizate pot reduce dificultatea pierderii unui singur dispozitiv. Tratarea fiecărei pierderi drept o urgență de recuperare completă ar ignora acel beneficiu. Secțiunea 6.1.3 a Recomandării datate deosebește posibilitatea de a salva o copie a credențialei de starea actuală a copiei și discută autentificatoare suplimentare sau recuperare pentru credențialele limitate la un dispozitiv. Distincția justifică întrebarea despre ce rămâne disponibil, în locul presupunerii că pierderea dispozitivului înseamnă mereu pierderea contului.

Beneficiul nu face toate căile de recuperare la fel de puternice. Dacă rămâne disponibilă o credențială utilizabilă, aplicația poate evalua în continuare un răspuns de autentificare. Dacă nu mai rămâne niciuna, aplicația decide pe baza altor dovezi. Produsul ar trebui să separe cazurile chiar dacă ambele restabilesc în cele din urmă accesul. Rezultate asemănătoare pentru client pot depinde de decizii de încredere diferite în mod semnificativ.

O obiecție rezonabilă este că un proces exigent poate bloca utilizatori legitimi. Echipa ar trebui să cântărească acest cost alături de accesul neautorizat. O politică restrictivă care nu poate fi explicată sau parcursă îi poate dezavantaja tocmai pe cei pe care vrea să îi protejeze. Acesta este un motiv pentru o recuperare utilizabilă și proporțională, nu pentru afirmația că orice alternativă comodă preia nivelul de încredere al credențialei principale.

Legați politica originilor de ciclul contului

Verificările de autentificare din secțiunea 7.2 sunt cerințe ale procedurii, nu formulări opționale care pot fi slăbite din comoditate. Alegerile separate ale produsului pentru recuperare ar trebui documentate alături de ele, astfel încât nicio echipă să nu presupună că cealaltă graniță furnizează dovezile lipsă. O decizie de asistență nu poate transforma o origine neașteptată într-una așteptată doar numind operația recuperare. Verificarea autentificării și autorizarea recuperării au fiecare nevoie de un temei valid.

O analiză de mentenanță poate urmări traseul utilizatorului peste ambele granițe. Citiți instrucțiunile contului alături de originile așteptate și de politica de recuperare. Căutați locurile unde instrucțiunile presupun existența unui autentificator deși problema declarată este pierderea tuturor. Căutați și promisiuni de restabilire garantată când aplicația nu a definit dovezi suficiente. Sunt neconcordanțe concrete ale produsului, pe care numele unui protocol nu le rezolvă.

Mentenanța software este un moment potrivit pentru păstrarea acestor decizii în acord pe măsură ce produsul se schimbă. Sursele stabilesc standardul datat și limitele verificării și ale stării copiei; nu verifică o anumită aplicație sau implementare de navigator. Rezultatul practic este o politică de recuperare numită, cu condiții clare. O cheie de acces poate întări conectarea obișnuită, iar produsul rămâne responsabil să explice cum se restabilește controlul contului când acea cale nu este disponibilă.