Cum adaugi autentificare în doi pași (2FA) în aplicația ta

Pentru a adăuga autentificare în doi pași (2FA) în aplicația ta, lasă utilizatorii să lege o aplicație de autentificare scanând un cod QR, cere codul de șase cifre pe care îl arată după parolă și creează o sesiune completă pe server doar după ce acel cod este verificat. Dă fiecărui utilizator coduri de recuperare de unică folosință când îl activează, limitează câte coduri poate ghici cineva și cere parola plus un cod curent înainte ca 2FA să poată fi dezactivat. Dacă folosești un furnizor de autentificare găzduit, activează opțiunea lui încorporată de autentificare multifactor în loc să construiești una proprie.

Acest ghid parcurge alegerile, fluxul exact, prompturi pe care le poți da unui constructor cu AI și greșelile care fac ca 2FA să pară prezentă, dar să nu facă nimic. Dacă conceptul este nou, începe cu ce este autentificarea în doi pași.

Înainte de start: ai nevoie de un login care funcționează

2FA stă deasupra unei autentificări existente. Ai nevoie de una dintre acestea întâi:

• Propriul tău login, cu utilizatori și parole hash-uite stocate în baza de date a aplicației tale.
• Un furnizor de autentificare găzduit care gestionează utilizatorii în locul tău.

Dacă nu ai niciunul încă, începe cu cum adaugi login în aplicația ta. Restul acestui ghid presupune că un pas cu parola funcționează deja.

Alege-ți al doilea factor

TOTP înseamnă time-based one-time password, standardul (RFC 6238) pe care îl folosesc aplicațiile de autentificare. Serverul tău și telefonul utilizatorului împart un secret; fiecare generează același cod scurt din acel secret și din ora curentă, de obicei schimbat la fiecare 30 de secunde. Nu este nevoie de conexiune la rețea sau de furnizor SMS.

Passkey-urile înlocuiesc sau completează parolele cu o cheie criptografică stocată pe dispozitivul utilizatorului. Sunt mai puternice, dar mai greu de construit singur, deci multe aplicații încep cu TOTP și adaugă passkey-uri mai târziu sau le primesc de la un furnizor de autentificare.

Îl construiești sau îl activezi?

Verifică documentația actuală a furnizorului tău pentru care factori suportă și pe ce planuri. Oricum ar fi, nu scrie niciodată singur matematica de generare a codurilor; folosește o bibliotecă larg utilizată.

Decide politica întâi

Răspunde la acestea înainte să scrii prompturile, pentru că schimbă designul:

1. Cine trebuie să o folosească? Opțională pentru toată lumea, obligatorie pentru admini și personal sau obligatorie pentru toți. Cerința pentru oricine are putere de admin este comună. Vezi controlul accesului pe bază de roluri.
2. Cât de des reintroduc utilizatorii un cod? La fiecare login sau o dată pe dispozitiv timp de 30 de zile („ține minte acest dispozitiv”).
3. Ce acțiuni cer o verificare proaspătă? Schimbarea emailului, a datelor de plată sau dezactivarea 2FA sunt candidate bune. Se numește autentificare pas-cu-pas (step-up authentication).
4. Care este procesul pentru telefonul pierdut? Coduri de recuperare, plus un plan manual de rezervă pe care ești dispus să îl rulezi.

Pas cu pas: 2FA TOTP pe propriul login

1. Stochează câmpurile potrivite

Fiecare utilizator are nevoie de: dacă 2FA este activat, secretul TOTP (criptat în repaus, nu text simplu), momentul activării și o listă de coduri de recuperare hash-uite, ca parolele. Adaugă un loc în care numeri încercările eșuate.

2. Înrolarea

1. Utilizatorul deschide Setările și apasă Activează autentificarea în doi pași.
2. Serverul generează un secret nou și îl returnează ca cod QR, plus versiunea text pentru cei care nu pot scana.
3. Utilizatorul îl scanează într-o aplicație de autentificare și tastează codul curent.
4. Serverul verifică codul. Doar dacă este corect salvează secretul și marchează 2FA ca activat.
5. Aplicația afișează 8–10 coduri de recuperare o singură dată și cere utilizatorului să le salveze.

Pasul 4 contează: activarea 2FA înainte să confirmi un cod blochează pe oricine a greșit scanarea.

3. Login cu un al doilea pas

1. Utilizatorul trimite emailul și parola. Serverul le verifică.
2. Dacă 2FA este activat, serverul nu creează o sesiune completă. În schimb, creează o stare de „al doilea factor în așteptare”, de scurtă durată.
3. Aplicația afișează ecranul cu codul. Serverul verifică codul, permițând o mică fereastră pentru decalajul de ceas.
4. Abia acum serverul emite sesiunea reală.

Fiecare rută protejată și endpoint API trebuie să respingă starea de așteptare. Un ecran 2FA care doar ascunde paginile în browser poate fi ocolit apelând API-ul direct.

4. Limite și alerte

Un cod de șase cifre are un milion de combinații, ceea ce se poate ghici fără limite. Limitează încercările, blochează al doilea pas pentru o perioadă după eșecuri repetate și trimite un email utilizatorului când se întâmplă asta. Vezi limitarea ratei și trimiterea de emailuri din aplicația ta.

5. Recuperarea și dezactivarea

• Un cod de recuperare funcționează o singură dată, apoi este șters.
• Dezactivarea 2FA cere parola și un cod curent sau un cod de recuperare.
• Regenerarea codurilor de recuperare invalidează setul vechi.
• Trimite un email utilizatorului ori de câte ori 2FA este activat sau dezactivat.

Prompturi pentru constructorul tău cu AI

Începe cu fluxul de bază:

Adaugă autentificare în doi pași opțională folosind aplicații de autentificare (TOTP) la login-ul nostru existent cu email și parolă. Folosește o bibliotecă TOTP cunoscută, nu scrie singur algoritmul. În Setări, afișează un cod QR și secretul text și activează 2FA doar după ce utilizatorul introduce un cod valid. Stochează secretul criptat și nu îl mai afișa după configurare. Afișează 10 coduri de recuperare de unică folosință o singură dată și stochează-le hash-uite.

Apoi aplicarea, unde codul generat greșește cel mai des:

Aplică 2FA pe server. După parola corectă, utilizatorii cu 2FA activat primesc o stare de așteptare de scurtă durată, nu o sesiune completă. Fiecare pagină și rută API protejată trebuie să respingă starea de așteptare. Limitează încercările de cod la 5, apoi blochează al doilea pas 15 minute și trimite un email utilizatorului.

Apoi politica:

Cere 2FA pentru conturile de admin: un admin fără 2FA este trimis la configurare și nu poate ajunge în panou până când nu o termină. Cere parola și un cod curent pentru a dezactiva 2FA sau a schimba emailul contului. Trimite un email utilizatorului când 2FA este activat sau dezactivat.

În final, cere agentului să explice ce a construit:

Listează fiecare rută care verifică un al doilea factor completat, unde sunt stocate secretul TOTP și codurile de recuperare și cum sunt protejate.

Greșeli frecvente

• Sesiune emisă după parolă. Cea mai serioasă greșeală. Dacă sesiunea completă există înainte ca codul să fie verificat, 2FA este doar decor. Testează apelând o rută API protejată doar după pasul cu parola.
• Fără limită de încercări. Ghicirile nelimitate fac codul vulnerabil la forță brută.
• Secrete sau coduri de recuperare în text simplu. O scurgere din baza de date predă al doilea factor al tuturor.
• Activare înainte de verificare. Utilizatorii care au scanat greșit sunt blocați la următorul login.
• Fără cale de recuperare. Fiecare telefon pierdut devine un tichet de suport sau un client pierdut.
• Dezactivare ușoară. Dacă o sesiune furată poate dezactiva 2FA fără cod, protecția dispare.
• Coduri în jurnale. Asigură-te că codurile și secretele nu apar niciodată în jurnalele serverului sau în mesajele de eroare.
• Verificarea doar pe pagina de login. Resetarea parolei, autentificarea prin „magic link” și orice login social trebuie să respecte și ele 2FA, altfel devin o cale de ocolire.

Lista de verificare a testării

• Înrolarea se finalizează doar după un cod valid
• Login cu parola corectă, dar fără cod, nu oferă acces la nicio pagină sau API protejat
• Un cod greșit este respins; încercările greșite repetate declanșează blocarea și un email
• Un cod de acum câteva minute este respins
• Fiecare cod de recuperare funcționează exact o dată
• Dezactivarea 2FA cere parola și un cod curent
• Resetarea parolei nu ocolește 2FA
• Adminii fără 2FA nu pot ajunge la paginile de admin (dacă este cerut)
• Secretele și codurile de recuperare sunt criptate sau hash-uite în baza de date
• Niciun cod sau secret nu apare în jurnale

Rulează și lista de verificare de securitate pentru aplicațiile construite cu AI completă înainte de lansare.

Adăugarea 2FA în Mythex

Mythex nu include un sistem de login încorporat pentru utilizatorii finali ai aplicației tale, deci 2FA face parte din abordarea de autentificare pe care o alegi: propriul login cu email și parolă folosind baza de date a proiectului sau un furnizor găzduit cu suport multifactor. Descrii ce vrei în chat, folosind prompturi ca cele de mai sus, iar cheile furnizorului merg în secretele proiectului (prin /secrets, setările proiectului sau cardul de secrete pe care îl arată agentul), nu în caseta de mesaje. Rețeta din documentație Adaugă login în aplicația ta are un prompt de pornire, iar Securitatea pentru aplicațiile pe care le construiești acoperă obiceiurile legate de chei și permisiuni. După ce agentul termină, testează fiecare punct din listă în Preview înainte să publici.

Întrebări