import * as argon2 from "argon2";
import * as bcrypt from "bcrypt";
interface User {
id: string;
passwordHash: string;
}
async function verifyAndMigratePassword(user: User, plainPassword: string): Promise<boolean> {
const isBcrypt = user.passwordHash.startsWith("$2a$") || user.passwordHash.startsWith("$2b$");
if (isBcrypt) {
const isValid = await bcrypt.compare(plainPassword, user.passwordHash);
if (!isValid) return false;
// Rehash automat cu Argon2id la login valid
const newHash = await argon2.hash(plainPassword, {
type: argon2.argon2id,
memoryCost: 65536, // 64 MB
timeCost: 3,
parallelism: 1,
});
await db.user.update({ where: { id: user.id }, data: { passwordHash: newHash } });
return true;
}
return argon2.verify(user.passwordHash, plainPassword);
}Încă văd proiecte pornite recent unde developerii pun bcrypt.hash(pass, 10) din reflex, doar pentru că așa au învățat dintr-un tutorial din 2018. Dacă ai un sistem de autentificare cu ceva vechime sau vrei să fii acoperit pe termen lung, bcrypt începe să-și arate limitele în fața GPU-urilor moderne.
În producție, trecerea la Argon2id nu mai e doar un moft de securitate teoretică, ci standardul recomandat de OWASP.
De ce pierde bcrypt teren în fața Argon2id
Bcrypt a fost excepțional timp de două decenii. Problema lui este că e pur CPU-bound și folosește foarte puțină memorie (doar 4 KB de L1 cache). Un cluster ieftin de plăci video RTX 4090 poate calcula sute de milioane de hash-uri bcrypt pe secundă dacă nimerește un leak de bază de date.
Argon2id rezolvă fix problema asta prin conceptul de memory-hardness. Îl forțezi pe atacator să aloce memorie RAM pentru fiecare încercare. Dacă setul tău de parametri cere 64 MB de RAM per operațiune, memoria plăcii video se umple instant și paralelizarea devine incredibil de scumpă pentru cel care încearcă atacul brute-force.
Cum alegi cost factor-ul corect
Nu copia orbește setările din documentație fără să măsori. Scopul este ca un hash să dureze între 250ms și 500ms pe serverul tău de producție. Mai puțin înseamnă că e prea ușor de spart; mai mult înseamnă că îți blochezi event loop-ul sau workerii la trafic intens.
La un proiect cu ~40k useri activi zilnic, pe instanțe de 4 vCPU, am calibrat parametrii astfel:
- Bcrypt (dacă încă îl ții): cost factor minim 12, ideal 13. La cost 10 un hash durează ~70ms, ceea ce e mult prea rapid.
- Argon2id:
memoryCost: 65536(64 MB),timeCost: 3iterații,parallelism: 1sau 2 (în funcție de câte core-uri are serverul).
Trade-off-ul sincer aici este riscul de DoS. Dacă un atacator trimite 100 de request-uri simultane pe endpoint-ul de login, serverul tău va aloca 6.4 GB de RAM doar pentru verificat parole. Soluția nu e să scazi costul hash-ului, ci să pui rate-limiting strict (ex: 5 încercări per IP/cont pe minut).
Strategia de migrare: rehash la login
Nu poți converti parolele în masă printr-un script de migrare de bază de date, pentru că nu ai parolele în clar (și sper că nu le ai salvate nicăieri). Soluția elegantă este migrarea leneșă (lazy rehash) direct în fluxul de autentificare.
Când un utilizator se loghează:
- Verifici formatul hash-ului existent din baza de date.
- Dacă e hash vechi de bcrypt, îl verifici cu
bcrypt.compare(). - Dacă parola e corectă, generezi imediat un hash nou cu
argon2.hash()și actualizezi câmpul în DB. - La următoarele logări, utilizatorul va fi verificat direct cu Argon2id.
După 6-9 luni, 80-90% din utilizatorii activi vor avea parolele migrate automat în Argon2id, fără să fi simțit vreo diferență și fără să fi trimis mailuri enervante de resetare a parolei. Restul de conturi inactive pot fi forțate la reset doar când decid să revină pe platformă.
Voi ce valori de cost rulați în prezent pe auth și când ați făcut ultimul benchmark pe mașinile de producție?