De ce te protejează, de fapt, hashingul unei parole

Versiunea scurtă

Hashingul unei parole protejează utilizatorii atunci când baza ta de date cu parole este furată.

Acesta este rolul principal. Nu singurul detaliu, nu întregul model de securitate, ci motivul central pentru care aplicăm hashing parolelor în loc să le stocăm direct.

O parolă hashuită corect este dificil de inversat. Dacă un atacator obține o copie a tabelului tău de utilizatori, nu ar trebui să afle imediat că parola lui Alice este Spring2026!. În schimb, primește un hash stocat, care necesită timp, bani și hardware pentru a fi testat împotriva presupunerilor.

Această distincție contează. Hashingul parolelor nu este menit să facă autentificarea sigură de unul singur. Nu oprește phishingul. Nu oprește pe cineva să încerce parole scurse în formularul tău de autentificare. Nu protejează un cookie de sesiune după autentificare. Cumpără timp și reduce daunele după un eșec foarte specific: stocarea verificatorilor de parole devine expusă.

Dacă înțelegi această limită, vei lua decizii mai bune despre algoritmi, factori de lucru, resetări, logare și răspuns la incidente.

Ce este un hash de parolă

Un hash de parolă este rezultatul unei funcții unidirecționale aplicate unei parole, de obicei cu un salt unic și cu un algoritm de hashing al parolelor deliberat lent.

Când un utilizator creează un cont, sistemul ar trebui să facă, în linii mari, următoarele:

1. Primește parola prin HTTPS.
2. Generează un salt aleatoriu, unic.
3. Rulează parola și saltul printr-o funcție de hashing a parolelor precum Argon2id, bcrypt, scrypt sau PBKDF2.
4. Stochează numele algoritmului, parametrii, saltul și hashul rezultat.
5. Aruncă parola originală.

Când utilizatorul se autentifică mai târziu, sistemul repetă același proces de hashing cu parola trimisă și parametrii stocați. Dacă hashul rezultat se potrivește cu hashul stocat, autentificarea reușește.

Partea importantă: aplicația nu trebuie să cunoască parola originală. Trebuie doar să verifice că parola trimisă produce rezultatul așteptat.

De aceea, stocarea parolelor cu criptare reversibilă este, de obicei, modelul greșit. Dacă aplicația ta poate decripta fiecare parolă, atunci oricine fură cheia de decriptare poate face același lucru. În mod normal, parolele ar trebui să fie neverificabile în sens invers, nu doar ascunse.

De ce te protejează hashingul

1. Dezvăluirea imediată a parolelor după o breșă a bazei de date

Dacă un atacator fură o bază de date care conține parole în clar, dauna este instantanee. Fiecare parolă este expusă. Utilizatorii sunt în pericol nu doar pe site-ul tău, ci oriunde au reutilizat acea parolă.

Dacă baza de date conține parole hashite corect, atacatorul are mai mult de lucru. Trebuie să ghicească parole candidate, să hashuiască fiecare presupunere cu saltul și parametrii corecți și să compare rezultatul.

Pentru parole slabe, acest lucru poate fi în continuare rapid. Pentru parole puternice și unice, poate fi impracticabil.

Hashingul transformă o dezvăluire catastrofală într-o cursă: pot utilizatorii să își reseteze parolele și poți tu să limitezi incidentul înainte ca atacatorii să spargă multe dintre ele?

Nu este perfect. Este tot o breșă. Dar este un mod de eșec dramatic mai bun.

2. Atacuri în masă împotriva întregii baze de utilizatori

Salturile sunt o parte esențială a stocării parolelor deoarece îi împiedică pe atacatori să atace eficient mulți utilizatori deodată cu tabele precalculate.

Un salt nu este secret. Este stocat împreună cu hashul. Rolul lui este unicitatea.

Dacă doi utilizatori aleg aceeași parolă, salturile unice asigură că hashurile lor stocate diferă. Asta îi împiedică pe atacatori să vadă dintr-o privire că mulți utilizatori au aceeași parolă. De asemenea, previne atacurile clasice cu tabele rainbow, în care atacatorii folosesc liste precalculate uriașe de mapări parolă-hash.

Fără salturi, un singur hash spart poate dezvălui fiecare utilizator cu aceeași parolă. Cu salturi, fiecare presupunere de parolă trebuie testată separat pentru fiecare utilizator.

3. Ghicit offline rapid

Odată ce atacatorii au o bază de date cu parole, pot ghici offline. Asta înseamnă că limitările de rată la autentificare, CAPTCHA, blocarea IP-urilor și monitorizarea nu mai contează. Atacatorul poate testa presupuneri pe propriul hardware.

Aici contează alegerea algoritmului.

Hashurile de uz general, precum SHA-256 și SHA-512, sunt proiectate să fie rapide. Acest lucru este bun pentru integritatea fișierelor și semnăturile digitale. Este rău pentru stocarea parolelor.

Algoritmii de hashing al parolelor sunt proiectați să fie lenți, configurabili și uneori memory-hard. Argon2id, bcrypt, scrypt și PBKDF2 îți permit toți să ajustezi parametrii de cost, astfel încât fiecare presupunere să necesite timp semnificativ.

Argon2id este recomandat pe scară largă pentru sisteme noi deoarece poate fi configurat să necesite atât timp CPU, cât și memorie, ceea ce face crackingul pe GPU la scară mare mai scump. bcrypt rămâne comun și acceptabil atunci când este configurat bine, deși are limitări precum gestionarea lungimii parolei. PBKDF2 este încă folosit în unele medii determinate de conformitate, mai ales acolo unde sunt necesare componente validate FIPS.

Principiul este simplu: fă autentificările legitime acceptabil de rapide, în timp ce faci miliarde de presupuneri costisitoare.

De ce nu te protejează hashingul

1. Phishing

Dacă un utilizator își tastează parola într-o pagină falsă de autentificare, hashingul de pe serverul tău nu ajută. Atacatorul primește parola înainte ca sistemul tău să o vadă vreodată.

Apărările de aici sunt diferite: autentificare multifactor, passkeys, educarea utilizatorilor, igiena domeniilor, autentificare rezistentă la phishing și fluxuri atente de resetare a parolei.

Hashingul parolelor este o plasă de siguranță pentru secrete stocate. Nu este o apărare împotriva utilizatorilor păcăliți să renunțe la acele secrete.

2. Credential stuffing

Credential stuffing se întâmplă atunci când atacatorii iau perechi de nume de utilizator și parole scurse de la un serviciu și le încearcă pe altul.

Hashurile tale de parole pot fi excelente, iar credential stuffing-ul poate funcționa totuși dacă utilizatorii reutilizează parole.

Acesta este un atac online împotriva formularului tău de autentificare, nu un atac offline împotriva bazei tale de date. Ai nevoie de limitare de rată, detectare de anomalii, verificări pentru parole compromise, MFA și politici de blocare rezonabile, care să nu creeze oportunități ușoare de denial-of-service.

Aceeași gândire practică se aplică oricărui formular expus. Dacă îți revizuiești suprafața de autentificare, merită să citești despre motivul pentru care formularul tău de contact este cea mai mare răspundere de spam; mecanicile diferă, dar lecția este similară: intrările publice au nevoie de controale împotriva abuzului, nu doar de cod backend curat.

3. Parole capturate în loguri sau analytics

Hashingul ajută doar dacă parola în clar este aruncată rapid și nu este copiată nicăieri altundeva.

Eșecurile comune includ:

• Logarea corpurilor complete ale cererilor la încercări eșuate de autentificare.
• Trimiterea parolelor către instrumente de monitorizare a erorilor.
• Capturarea câmpurilor de parolă în produse de session replay.
• Includerea credențialelor în URL-uri în timpul unor fluxuri de resetare sau migrare prost proiectate.
• Stocarea temporară a parolelor în clar în timpul importurilor.

Aceste greșeli ocolesc complet hashingul parolelor. Dacă textul în clar ajunge în loguri, backupuri, data warehouses sau instrumente terțe, funcția ta de hashing este irelevantă.

Tratează câmpurile de parolă ca date toxice. Redactează-le înainte de logare. Exclude-le din analytics. Ține-le în afara URL-urilor. Limitează cine poate accesa urmele de producție.

4. Securitate slabă a sesiunilor

După autentificare, browserul utilizatorului primește de obicei un cookie sau token de sesiune. Dacă acel token este furat, atacatorul poate să nu mai aibă deloc nevoie de parolă.

Hashingul parolelor nu protejează împotriva cross-site scripting, cookie-urilor nesigure, session fixation, generării slabe de tokenuri sau duratelor de viață prea lungi ale sesiunilor.

Cookie-urile de sesiune merită propria revizuire: HttpOnly, Secure, SameSite adecvat, sesiuni cu risc ridicat de scurtă durată și invalidare pe server la schimbarea parolei. Peisajul mai larg al confidențialității și al browserelor continuă și el să se schimbe, așa cum este acoperit în ce s-a schimbat pentru cookie-uri în 2026.

5. Resetare slabă a parolei și recuperare de cont

Multe preluări de conturi nu încep cu parola. Încep cu fluxul de resetare.

Dacă tokenurile de resetare sunt predictibile, au durată lungă de viață, se scurg prin antete referrer sau sunt trimise către conturi de email compromise, hashingul parolelor nu te va salva.

Folosește tokenuri de resetare cu entropie ridicată, ferestre scurte de expirare, utilizare unică și notificări clare pentru utilizatori. Deoarece emailul este adesea canalul de recuperare, contează și autentificarea de bază a domeniului. Dacă echipa ta tratează înregistrările DNS ca pe o ceremonie misterioasă, începe cu un tur prietenos pentru dezvoltatori al MX, SPF, DKIM și DMARC.

Alegerea algoritmului: ce să folosești acum

Pentru aplicații noi, folosește Argon2id dacă platforma ta îl suportă bine. Este câștigătorul Password Hashing Competition și este proiectat pentru stocarea parolelor, inclusiv rezistența la cracking intens pe GPU.

O ierarhie modernă rezonabilă arată astfel:

1. Argon2id pentru sisteme noi unde este disponibil.
2. bcrypt când Argon2id nu este practic și suportul pentru bcrypt este matur.
3. scrypt când configurația memory-hard este bine suportată.
4. PBKDF2 acolo unde este cerut de constrângeri de platformă sau conformitate.

Evită SHA-256 simplu, SHA-512, MD5 sau o combinație făcută în casă precum sha256(password + salt). Hashurile rapide nu sunt funcții de stocare a parolelor. Construcțiile personalizate ingenioase tind să fie mai rele decât cele standard și plictisitoare.

De asemenea, evită să inventezi propria politică de parole în jurul unor detalii triviale de algoritm. Utilizatorii nu beneficiază de o listă de verificare cu 12 reguli de compoziție a parolei dacă aceasta îi împinge către tipare predictibile. Parolele mai lungi și unice, managerii de parole, verificarea parolelor compromise și MFA contează de obicei mai mult.

Factorii de cost nu sunt ceva ce setezi și uiți

Hashingul parolelor are parametri. Argon2id are memorie, iterații și paralelism. bcrypt are un factor de cost. PBKDF2 are un număr de iterații.

Aceste valori ar trebui alese pe baza mediului tău de producție. Prea mici, iar atacatorii ghicesc ieftin. Prea mari, iar sistemul tău de autentificare devine lent sau vulnerabil la denial-of-service.

O țintă practică este adesea în intervalul de la zeci până la câteva sute de milisecunde per verificare de parolă pe serverele tale reale, în funcție de trafic și risc. Sistemele de securitate înaltă pot alege mai mult. Sistemele la scară de consumatori pot avea nevoie de planificare atentă a capacității.

Nu copia un factor de cost dintr-un articol de blog vechi de cinci ani. Hardware-ul se schimbă. Bibliotecile se schimbă. Traficul tău se schimbă.

Revizuiește periodic parametrii și planifică rehashingul. Un tipar comun este să stochezi algoritmul și parametrii împreună cu fiecare hash. La o autentificare reușită, dacă parametrii stocați sunt depășiți, rehashuiești parola trimisă cu configurația mai nouă și actualizezi înregistrarea.

Peppers: utile, dar nu un substitut

Un pepper este o valoare secretă adăugată în procesul de hashing al parolelor și stocată separat de baza de date, adesea într-un manager de secrete sau într-un modul hardware de securitate.

Spre deosebire de un salt, un pepper trebuie să rămână secret.

Peppers pot reduce daunele dacă baza de date se scurge, dar secretele aplicației nu. Sunt cele mai utile în medii mature, cu management bun al cheilor. Sunt mai puțin utile dacă același atacator poate fura atât baza de date, cât și configurația aplicației.

Dacă folosești un pepper, planifică atent rotația. Rotirea lui poate necesita ca utilizatorii să se autentifice din nou sau să își reseteze parolele, în funcție de design. Un pepper este un strat suplimentar, nu un motiv să slăbești setările hashului de bază.

Lista de verificare operațională

Dacă ești responsabil pentru un sistem real, lista practică de verificare este scurtă:

• Stochează parolele doar cu un algoritm standard de hashing al parolelor.
• Folosește un salt aleatoriu unic pentru fiecare parolă.
• Preferă Argon2id pentru proiecte noi.
• Ajustează parametrii de cost pe hardware similar cu producția.
• Stochează algoritmul și parametrii împreună cu fiecare hash.
• Rehashuiește la autentificare când parametrii devin depășiți.
• Nu loga niciodată parole și nu le trimite către instrumente de analytics.
• Folosește TLS oriunde sunt trimise credențiale.
• Adaugă MFA sau passkeys acolo unde riscul o justifică.
• Protejează fluxurile de resetare la fel de serios ca fluxurile de autentificare.
• Ai un plan de incident pentru resetări forțate și notificarea utilizatorilor.

Hashingul parolelor nu este spectaculos. Este instalație. Dar este genul de instalație care determină dacă o breșă devine un incident dureros sau un dezastru la nivelul tuturor utilizatorilor.

<!-- tool-cta:start -->

💡 Încearcă asta: Vezi cum aceeași intrare este mapată la algoritmi diferiți cu Hash Generator, care face concretă diferența dintre hashurile rapide și cele de nivel potrivit pentru parole.

<!-- tool-cta:end -->

Modelul mental onest

Cel mai bun mod de a te gândi la hashingul parolelor este acesta:

Hashingul nu protejează parola în timp ce utilizatorul o tastează. Nu protejează contul după ce utilizatorul este autentificat. Nu protejează utilizatorii care reutilizează parole pe web.

Protejează verificatorul stocat.

Sună îngust, dar este extrem de important. Bazele de date se scurg. Backupurile se scurg. Sistemele de staging sunt copiate. Furnizorii primesc acces pe care nu ar trebui să îl aibă. Exporturi vechi rămân în object storage mai mult decât își amintește cineva.

Când se întâmplă asta, designul tău de stocare a parolelor devine diferența dintre atacatori care primesc parole și atacatori care primesc o problemă de ghicit costisitoare.

Aceasta este, de fapt, protecția pe care ți-o oferă hashingul unei parole.