eduardweb.
Securitate & AuthIntermediar#backend#best-practices#securitate#node-js#argon2

Password hashing în 2026: De ce trebuie să lași bcrypt în urmă și cum migrezi la Argon2id

De Cristian Barbu, 23 mai 2026 · 5 vizualizări · 3 like-uri

Postat 23 mai 2026
typescript
import argon2 from 'argon2';
import bcrypt from 'bcrypt';

async function verifyAndMigratePassword(password: string, userRecord: any): Promise<boolean> {
  const isArgonHash = userRecord.passwordHash.startsWith('$argon2');

  if (isArgonHash) {
    return await argon2.verify(userRecord.passwordHash, password);
  }

  // Dacă e hash vechi, verificăm cu bcrypt
  const isValidBcrypt = await bcrypt.compare(password, userRecord.passwordHash);
  
  if (isValidBcrypt) {
    // Migrăm userul la Argon2id în fundal
    const newHash = await argon2.hash(password, {
      type: argon2.argon2id,
      memoryCost: 65536, // 64MB
      timeCost: 3,
      parallelism: 4
    });
    
    await db.users.update(userRecord.id, { passwordHash: newHash });
    return true;
  }

  return false;
}

Ne-am obișnuit toți să aruncăm un bcrypt.hash(password, 10) în cod și să ne vedem de viață. A funcționat excelent mulți ani, dar în 2026 abordarea asta e deja leneșă și destul de riscantă. Puterea de calcul a plăcilor video moderne a explodat, iar bcrypt nu mai ține pasul eficient.

Hai să vorbim sincer despre de ce trebuie să facem trecerea la Argon2id, ce parametri folosim în producție și cum implementăm o migrare graduală fără să resetăm parolele utilizatorilor.

De ce Bcrypt e depășit în 2026

Bcrypt a fost lansat în 1999. Este un algoritm genial, dar are o limitare structurală majoră: este limitat doar de CPU (core-bound). Nu are nevoie de memorie RAM ca să ruleze.

Pentru un atacator, asta e o veste minunată. Cu câteva sute de dolari, poate închiria instanțe GPU pe AWS și poate rula miliarde de încercări de spargere pe secundă pe un dump de bază de date. Dacă vrei să faci bcrypt sigur astăzi, trebuie să urci cost factor-ul la 12 sau 13. Asta înseamnă că o singură verificare de parolă pe serverul tău va dura peste 350-400ms. La un trafic mediu, îți blochezi event loop-ul sau umpli thread-urile inutil.

Argon2id (câștigătorul competiției Password Hashing Competition) rezolvă exact problema asta prin conceptul de memory hardness. Îl poți configura să consume nu doar CPU, ci și o cantitate specifică de memorie RAM. Plăcile video au memorie ultra-rapidă, dar limitată per nucleu de calcul. Când forțezi algoritmul să folosească 64MB de RAM per hashing, atacul pe GPU devine incredibil de scump și ineficient.

Parametrii corecți pentru Argon2id

Am făcut trecerea asta anul trecut pe un proiect cu 80.000 de utilizatori activi. După mai multe teste de încărcare direct în containerele de producție (care aveau limite de 2 vCPUs), am stabilit următoarea configurație echilibrată:

  • Memory (m): 65536 (adică 64 MB). Este destul de mult ca să blocheze atacurile hardware, dar destul de puțin ca serverul să nu crape sub sarcină.
  • Iterations (t): 3. Numărul de treceri prin memorie.
  • Parallelism (p): 4. Numărul de thread-uri folosite simultan de algoritm.

Configurația asta ne-a oferit un timp de răspuns de aproximativ 150ms per hashing. E perfect pentru UX și extrem de sigur.

Trade-off-ul sincer: Argon2id e o armă cu două tăișuri. Dacă ai un endpoint de login public și cineva îți trimite 100 de request-uri simultane cu parole greșite, serverul tău va încerca să aloce instant 6.4 GB de RAM (100 x 64MB). Dacă nu ai rate limiting agresiv pe ruta de login, riști un crash rapid prin Out-of-Memory (OOM). Bcrypt e mai iertător aici, fiindcă doar îți va urca CPU-ul în 100%, dar nu va prăbuși procesul din lipsă de RAM.

Strategia de migrare graduală (Lazy Migration)

Evident, nu poți să resetezi parolele tuturor utilizatorilor din baza de date și nici nu le ai în clar ca să le re-hashezi direct. Soluția este migrarea "on-the-fly" (sau lazy migration).

Când un utilizator se loghează:

  1. Verifici dacă hash-ul din baza de date este de tip Argon2id.
  2. Dacă este, folosești Argon2id pentru validare.
  3. Dacă este hash de tip vechi (bcrypt), validezi cu bcrypt.
  4. Dacă parola este corectă, generezi imediat un hash nou folosind Argon2id și îl salvezi în baza de date peste cel vechi.

În felul acesta, în câteva săptămâni, toți utilizatorii activi vor fi migrați automat la noul algoritm, fără ca măcar să observe vreo diferență.

Voi cum stați cu securitatea credentialelor în proiectele active? Ați făcut deja pasul spre Argon2id sau bcrypt încă își face treaba în setup-ul vostru?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.