import * as argon2 from 'argon2';
import * as bcrypt from 'bcrypt';
export async function verifyAndUpgradePassword(
plainText: string,
storedHash: string,
updateUserHash: (newHash: string) => Promise<void>
): Promise<boolean> {
// 1. Verificăm dacă e hash vechi de tip bcrypt
if (storedHash.startsWith('$2a$') || storedHash.startsWith('$2b$')) {
const isValid = await bcrypt.compare(plainText, storedHash);
if (!isValid) return false;
// 2. Parola e corectă, generăm hash-ul nou cu Argon2id
const newHash = await argon2.hash(plainText, {
type: argon2.argon2id,
memoryCost: 65536, // 64 MB
timeCost: 3,
parallelism: 1,
});
await updateUserHash(newHash);
return true;
}
// 3. Altfel, verificăm direct cu Argon2id
return await argon2.verify(storedHash, plainText);
}Dacă deschizi un cod de backend scris acum cinci ani, sunt 95% șanse să găsești un bcrypt.hash(password, 10). Funcționează, nu crapă, dar dacă îți scapă baza de date mâine, costul ăla de 10 e o glumă pentru oricine are acces la un cluster decent de GPU-uri. Hai să vedem de ce Argon2id a devenit alegerea implicită și cum faci trecerea fără să forțezi utilizatorii să-și schimbe parola.
Problema cu bcrypt în fața plăcilor video
Bcrypt a fost gândit în 1999 și e un algoritm strict CPU-bound. La vremea aia a fost genial, dar are o limitare structurală: nu consumă memorie deloc (vreo 4 KB per hash). Asta înseamnă că un atacator poate pune mii de nuclee dintr-un RTX 4090 să calculeze hash-uri în paralel fără nicio penalizare de memorie.
La un proiect cu vreo 40k useri activi unde făceam audit, am făcut un test intern: pe un hashcat cu un singur GPU decent, bcrypt cu cost 10 genera peste 120.000 de încercări pe secundă. Când am urcat costul la 12, timpul de răspuns pe endpoint-ul de login a sărit la 320ms pe instanțe de 1 vCPU. Dacă ai 50 de logări simultane pe un container mic, CPU-ul stă în 100% și începi să pierzi request-uri.
Argon2 (mai exact varianta Argon2id) rezolvă problema asta prin memory-hardness. Nu forțează doar procesorul, ci cere intenționat memorie RAM pentru a calcula fiecare hash. Pe GPU sau ASIC, memoria e scumpă și greu de partajat masiv, ceea ce face atacurile brute-force incredibil de costisitoare financiar.
Ce parametri alegi pentru Argon2id
Nu folosi setările default din primele tutoriale de pe net fără să le testezi pe mașina de producție. Eu merg pe recomandările curente OWASP, adaptate la containere de backend standard:
- Memory (m):
65536(adică 64 MB). Dacă ai containere serverless sau pods de Kubernetes cu doar 128 MB RAM alocați, o să iei OOM (Out Of Memory) rapid la câteva logări paralele. Dacă ești strâns cu memoria, cobori la32768(32 MB), dar niciodată sub 19 MB. - Iterations (t):
2sau3. Mai multe iterații cresc liniar timpul pe CPU, dar nu ajută la fel de mult ca memoria. - Parallelism (p):
1sau2(depinde câte nuclee reale are mașina ta; pe un vCPU single-core lași1).
Trade-off-ul e cinstit: Argon2id îți dă securitate masiv mai bună la un timp de execuție rezonabil (~150ms), dar mănâncă RAM. Dacă rulezi backend-ul pe un VPS micuț cu 512 MB RAM unde ai și Postgres și Node/Go, o să simți presiunea.
Cum migrezi fără să ceri reset de parole
Cea mai proastă idee e să trimiți mail la toți utilizatorii cu „Ne-am actualizat securitatea, resetați parola”. Jumătate vor crede că e phishing, ceilalți se vor enerva și nu se mai întorc.
Strategia corectă e re-hash la autentificare (Just-In-Time). Procesul e simplu: userul trimite parola în clar prin HTTPS, verifici hash-ul existent din DB. Dacă încă folosește prefixul vechi de bcrypt ($2b$ sau $2a$), rulezi verificarea cu bcrypt. Dacă parola e validă, generezi imediat un hash nou cu Argon2id, îl salvezi în baza de date și lași request-ul să treacă.
În câteva săptămâni, 70-80% dintre userii activi vor avea parolele migrate transparent, fără să observe nimic în UI.
Ce strategie folosiți acum pe proiectele voastre — ați făcut trecerea la Argon2id sau stați încă pe bcrypt cu cost factor ridicat?