import bcrypt from 'bcrypt';
import argon2 from 'argon2';
async function verifyAndUpgradePassword(password: string, storedHash: string): Promise<boolean> {
const isArgon2 = storedHash.startsWith('$argon2id$');
if (isArgon2) {
return await argon2.verify(storedHash, password);
}
// Fallback pe bcrypt pentru hash-urile vechi
const isValidBcrypt = await bcrypt.compare(password, storedHash);
if (isValidBcrypt) {
// Migrăm userul pe noul standard direct în background
const newHash = await argon2.hash(password, {
memoryCost: 19456, // 19 MB
timeCost: 2,
parallelism: 1
});
await saveToDatabase(newHash); // Funcția ta de update în DB
return true;
}
return false;
}Hai să vorbim direct. Dacă în 2026 încă mai ai bcrypt cu cost factor de 10 în producție doar pentru că "așa era în boilerplate-ul de Express din 2018", avem o problemă de securitate. Nu e panică, toți am trecut prin asta, dar e timpul să facem un upgrade serios.
Am pățit-o acum doi ani la un proiect cu vreo 12.000 de useri activi. La un audit de securitate extern, băieții ne-au atras atenția că hash-urile noastre bcrypt erau mult prea ușor de spart offline pe un rig de GPU-uri moderne. Atunci m-am pus pe documentat și am trecut totul pe Argon2id.
Bcrypt vs Argon2id: Care-i faza?
Bcrypt a fost lansat în 1999. E excepțional de bun pentru vremea lui, dar are o mare problemă în prezent: e legat exclusiv de CPU. Asta înseamnă că atacatorii pot folosi plăci video de ultimă generație sau cipuri FPGA customizate pentru a calcula milioane de hash-uri pe secundă.
Argon2id (câștigătorul Password Hashing Competition) e diferit. Este un algoritm de tip memory-hard. Pe lângă CPU, el cere și o cantitate configurabilă de memorie RAM pentru a genera hash-ul. Deoarece plăcile video nu pot aloca memorie RAM dedicată atât de ușor pentru fiecare nucleu în paralel, atacurile brute-force pe GPU devin extrem de scumpe și ineficiente.
Dar există și un trade-off sincer. Argon2id e mult mai complex de configurat. La bcrypt ai un singur parametru: rounds (work factor). La Argon2id ai trei variabile de care trebuie să ai grijă: memoria (m), iterațiile (t) și paralelismul (p). Dacă le pui prea mari pe un container mic de microservicii (de exemplu, o instanță ieftină cu 512MB RAM), riști să îți blochezi serverul la fiecare tentativă de login.
Cost factor corect în 2026
Dacă ești blocat pe Bcrypt, costul minim în 2026 este 12. Fiecare incrementare dublează timpul de calcul. La un cost de 12, generarea unui hash durează cam 250ms pe un procesor modern. Tot ce e sub cost 10 e periculos de rapid.
Dacă folosești Argon2id, recomandările actuale de la OWASP pentru un server web standard sunt:
- Memorie (
m):19456(adică 19 MB) - Iterații (
t):2 - Paralelism (
p):1(sau numărul de nuclee pe care vrei să le aloci procesului)
Am testat configurația asta pe un server t3.medium în AWS. Timpul de răspuns la login a rămas sub 150ms, ceea ce e perfect pentru UX și suficient de greu pentru un atacator.
Migrarea graduală (fără resetare de parole)
Cea mai mare greșeală e să crezi că trecerea la un algoritm nou înseamnă să le ceri tuturor userilor să își schimbe parola. Poți face asta elegant prin lazy migration (migrare la login).
Când userul introduce parola:
- Verifici dacă hash-ul din baza de date începe cu prefixul de Argon2id (de obicei
$argon2id$). - Dacă nu, înseamnă că e hash-ul vechi (bcrypt). Verifici parola folosind algoritmul bcrypt.
- Dacă parola e corectă, generezi imediat noul hash cu Argon2id și îl suprascrii în baza de date.
În felul ăsta, baza de date se curăță singură pe măsură ce oamenii se loghează activ. După câteva luni, poți rula un script care să trimită un mail de resetare doar pentru cei 5-10% de useri complet inactivi care au rămas pe hash-ul vechi.
Voi ce folosiți în stack-ul actual? Ați făcut trecerea la Argon2id sau bcrypt e încă "good enough" pentru ce aveți în producție?