Stocarea parolelor este unul dintre puținele domenii din software cu un răspuns corect autentic, publicat, întreținut și gratuit. Este totodată unul dintre cele mai constant greșite, pentru că răspunsurile greșite au fost corecte la un moment dat și nimeni nu le-a mai revizuit de atunci.
Eșecul este rareori exotic. Este un sistem construit în 2016 după recomandări care erau de actualitate în 2012, care încă rulează, care încă acceptă autentificări, și în a cărui funcție de hashing nu s-a mai uitat nimeni de când a plecat persoana care o scrisese.
Dacă reții un singur lucru: folosește Argon2id, iar dacă nu poți, folosește bcrypt. Tot restul acestui articol este detaliu. O funcție de hash de uz general precum SHA-256 nu este un hash de parolă, indiferent de câte ori o aplici, pentru că viteza ei este un obiectiv de proiectare, iar viteza este exact ceea ce încerci să îi refuzi unui atacator care îți are baza de date.
Stocarea parolelor are exact o singură formă corectă
Păstrează un hash produs de o funcție deliberat lentă și consumatoare de memorie, cu un salt aleatoriu unic pentru fiecare parolă, folosind parametri ajustați pentru hardware-ul tău.
Ghidul OWASP privind stocarea parolelor enunță precis recomandările curente, iar acestea merită citate ca cifre, nu ca principii.
| Algoritm | Parametri recomandați | Când se folosește |
|---|---|---|
| Argon2id | 19 MiB memorie, 2 iterații, 1 grad de paralelism | Prima alegere |
| scrypt | N=2^17 (128 MiB), r=8, p=1 | Dacă Argon2id nu este disponibil |
| bcrypt | Work factor 10 sau mai mare, limită de 72 byte pentru parolă | Sisteme vechi |
| PBKDF2-HMAC-SHA256 | 600.000 iterații | Acolo unde este cerută conformitatea FIPS-140 |
Două observații despre acest tabel. Cifra pentru Argon2id este un minim, iar mai multă memorie cu mai puține iterații este un schimb echivalent, așa că o configurație de 47 MiB cu 1 iterație oferă o securitate comparabilă cu linia de bază. Iar limita de 72 byte a lui bcrypt este o trunchiere reală, nu o regulă de validare: tot ce trece de 72 byte este ignorat în tăcere, ceea ce contează dacă accepți fraze de acces lungi sau dacă aplici un hash preliminar asupra intrării.
Acești parametri sunt revizuiți pe măsură ce hardware-ul avansează. Când implementezi, citește sursa și nu acest tabel.
Un salt nu este opțional și nu este suficient
Un salt este o valoare aleatorie unică păstrată alături de fiecare hash. Scopul lui este îngust și important: se asigură că doi utilizatori cu aceeași parolă produc hash-uri diferite, ceea ce anulează tabelele curcubeu precalculate și împiedică un atacator să spargă o singură parolă și să obțină fiecare cont care o folosea.
Ceea ce un salt nu face este să încetinească pe cineva. Un atacator care îți are baza de date are și salturile, pentru că ele trebuie să fie lizibile pentru a verifica o autentificare. Doar sărarea, în fața unui hash rapid, înseamnă că atacatorul atacă fiecare parolă individual, cu o viteză enormă, adică exact situația pe care voiai să o eviți.
Lentoarea trebuie să vină din algoritm. Acesta este întregul rost al unei funcții consumatoare de memorie: ea consumă resurse în mod deliberat, astfel încât un atacator cu hardware specializat să câștige mult mai puțin avantaj decât ar obține împotriva unui hash rapid.
Un pepper, o valoare secretă aplicată fiecărei parole și păstrată în afara bazei de date, adaugă un strat real, pentru că o simplă copie a bazei nu mai este suficientă. Adaugă și o povară operațională, fiindcă rotirea lui cere rehashing la următoarea autentificare, iar pierderea lui blochează fiecare cont. Merită pentru sistemele de mare valoare și poate fi omis pentru majoritatea.
Greșelile care supraviețuiesc ani la rând
Un hash rapid cu salt. SHA-256 cu un salt arată responsabil și nu este. Viteza este vulnerabilitatea.
Criptare în loc de hashing. Criptarea este reversibilă prin proiectare, deci există o cheie, iar cine o obține obține fiecare parolă în clar. Parolele nu trebuie să fie niciodată recuperabile, ci doar verificabile.
Work factor setat o dată și niciodată ridicat. Un cost bcrypt ales în 2015 este semnificativ mai slab față de hardware-ul din 2026. Ridică-l la următoarea autentificare reușită, când ai o clipă textul în clar și poți reface hash-ul.
Trunchiere sau restricții de caractere. O lungime maximă sub aproximativ 64 de caractere, sau interzicerea anumitor caractere, semnalează de obicei că parola este păstrată într-un fel căruia îi pasă ce conține. Nu ar trebui să îi pese, pentru că oricum o treci printr-o funcție de hash.
O comparație care scurge informație prin timp. Verificarea trebuie să folosească o comparație în timp constant. Funcțiile din bibliotecile standard fac asta, verificările de egalitate scrise de mână nu.
Scrierea parolei în jurnale. Ajunge într-un jurnal de erori, într-o urmă de cerere sau într-un sistem de monitorizare, iar de acolo se află în trei locuri cu controale de acces mai slabe decât ale bazei de date.
Migrarea unui sistem existent
Nu poți reface hash-ul a ceva ce nu ai, pentru că deții doar hash-uri. Abordarea funcțională este actualizarea la autentificare.
Când un utilizator se autentifică cu succes, ai parola lui în clar în memorie pentru o clipă. Verific-o față de hash-ul vechi, apoi calculează imediat unul nou cu algoritmul curent și înlocuiește valoarea stocată. În câteva luni, majoritatea conturilor active migrează fără nicio schimbare vizibilă pentru utilizator.
Ține evidența algoritmului la nivel de înregistrare, ca cele două să poată coexista, și fixează o dată după care hash-urile vechi rămase sunt invalidate, iar acei utilizatori trebuie să își reseteze parola. Conturile inactive cu hash-uri slabe sunt exact cele pe care le vrea un atacator.
Nu împacheta hash-ul vechi în algoritmul nou ca scurtătură. Funcționează, și lasă hash-ul slab drept graniță de securitate efectivă, în timp ce totul pare modern.
Ce contează mai mult decât algoritmul
Un hashing corect te protejează când baza de date se scurge. Nu face nimic împotriva atacului mai frecvent, adică cineva care se autentifică cu o parolă reală obținută în altă parte.
Limitarea ratei la autentificare, disponibilitatea autentificării multifactor, verificarea parolelor noi față de listele de credențiale deja compromise și alertele pe tiparele de credential stuffing rezolvă tocmai asta, și toate contează zilnic mai mult decât alegerea dintre Argon2id și bcrypt. Controalele de securitate API fac parte din aceeași familie de probleme.
Ambele merită făcute, iar ordinea merită spusă cinstit: rezolvă hashing-ul o singură dată, pentru că este ieftin și permanent, apoi cheltuiește efortul continuu pe traseul de autentificare, acolo unde ajung de fapt atacurile. Mecanik le analizează pe amândouă în cadrul serviciului nostru de analiză a securității aplicațiilor.
Întrebări frecvente
Care este cel mai bun algoritm de hashing pentru parole în 2026? Argon2id, cu minimum 19 MiB de memorie, 2 iterații și 1 grad de paralelism. Dacă nu este disponibil, scrypt cu N=2^17, r=8, p=1 este o alternativă, bcrypt cu un work factor de 10 sau mai mare se potrivește sistemelor vechi, iar PBKDF2-HMAC-SHA256 cu 600.000 iterații acoperă cerințele FIPS-140.
Este suficient să sărezi parolele? Nu. Un salt asigură că parole identice produc hash-uri diferite, anulează tabelele curcubeu și împiedică o singură parolă spartă să deschidă fiecare cont care o folosea. Nu încetinește atacatorul, pentru că salturile trebuie să fie lizibile pentru a verifica autentificările. Lentoarea trebuie să vină dintr-un algoritm deliberat consumator de memorie.
De ce să nu folosești SHA-256 pentru parole? Pentru că viteza lui este un obiectiv de proiectare, iar viteza este exact ceea ce încerci să îi refuzi unui atacator care îți deține baza de date. O funcție de hash de uz general nu este un hash de parolă, indiferent de câte ori este aplicată sau dacă este sărată.
Are bcrypt o limită de lungime pentru parolă? Da, 72 byte, iar tot ce depășește este trunchiat în tăcere, nu respins. Contează dacă accepți fraze de acces lungi sau dacă aplici un hash preliminar asupra intrării înainte de a o trimite la bcrypt, fiindcă trunchierea se produce fără nicio eroare care să o semnaleze.
Cum actualizez hash-urile de parolă fără parolele utilizatorilor? La autentificare. Când un utilizator se autentifică, îi deții o clipă textul în clar, deci verifici față de hash-ul vechi și refaci imediat hash-ul cu algoritmul curent. Ține evidența algoritmului la nivel de înregistrare, ca cele două să coexiste, și fixează o dată după care hash-urile vechi rămase sunt invalidate, iar acei utilizatori trebuie să își reseteze parola.
Comentarii