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

Password hashing în 2026: De ce bcrypt nu mai este de ajuns și cum migrezi la Argon2id

De Gabriela Neagu, 18 iul. 2026 · 11 vizualizări · 2 like-uri

Postat 18 iul. 2026
typescript
import bcrypt from 'bcrypt';
import argon2 from 'argon2';

async function loginAndMigrate(password: string, user: any): Promise<boolean> {
  // Bcrypt are hash-urile care încep de obicei cu $2a$ sau $2b$
  const isLegacyBcrypt = user.passwordHash.startsWith('$2b$') || user.passwordHash.startsWith('$2a$');

  if (isLegacyBcrypt) {
    const isValid = await bcrypt.compare(password, user.passwordHash);
    if (isValid) {
      // Parola e corectă, generăm hash-ul nou cu Argon2id
      const newHash = await argon2.hash(password, {
        type: argon2.argon2id,
        memoryCost: 65536, // 64 MB - ajustează în funcție de server
        timeCost: 3,
        parallelism: 4
      });
      
      await db.updateUserHash(user.id, newHash);
      return true;
    }
  } else {
    // Deja este pe Argon2id
    return await argon2.verify(user.passwordHash, password);
  }
  
  return false;
}

Dacă încă folosești bcrypt cu cost factor de 10 doar pentru că „așa era în tutorial”, ai o problemă de securitate în 2026. Hardware-ul de atac a devenit incredibil de ieftin, iar algoritmul tău preferat din 1999 începe să-și arate vârsta. Hai să vedem de ce Argon2id e noul standard și cum muți baza de date fără să obligi userii să-și reseteze parolele.

De ce ne lasă bcrypt în urmă?

bcrypt este un algoritm grozav, dar are o limitare majoră: este legat strict de performanța CPU-ului. Asta înseamnă că un atacator care folosește plăci grafice moderne sau cipuri custom (FPGA/ASIC) poate rula mii de încercări de decriptare în paralel, extrem de ieftin.

Argon2id (câștigătorul Password Hashing Competition) vine cu un concept diferit numit memory-hardness. Pe lângă timp, el cere și o cantitate specifică de memorie RAM pentru a calcula hash-ul. Deoarece memoria RAM este mult mai scumpă și mai greu de integrat în paralel pe un GPU, costul unui atac offline crește exponențial.

Trade-off-ul sincer: Securitate vs Resurse

Am pățit-o acum un an la o platformă cu 40k useri activi. Am zis să trecem direct la Argon2id cu setările recomandate de OWASP: memoryCost: 65536 (64MB), timeCost: 3 și parallelism: 4.

Totul a fost frumos în staging. În producție însă, la prima campanie de marketing când am avut un vârf de login-uri simultane, containerul de Node.js a fost omorât instant de OOM (Out Of Memory) Killer.

Aici e trade-off-ul:

  • Argon2id oferă o securitate excepțională împotriva atacurilor brute-force pe baza de date furată.
  • În schimb, te expune la un Denial of Service (DoS) extrem de ușor pe endpoint-ul de login dacă serverul tău nu are destul RAM.

Dacă ai un VPS ieftin cu 1GB RAM total, setările OWASP te vor îngropa. În cazul ăsta, e mai bine să rămâi pe un bcrypt cu cost factor 12 (care ia cam 250-300ms pe un thread modern) decât să pui un Argon2id subdimensionat care nu oferă niciun avantaj real.

Strategia de migrare graduală (fără downtime)

Cea mai mare greșeală pe care o poți face este să forțezi toți utilizatorii să își reseteze parolele duminică noaptea. Oamenii urăsc asta și vei pierde clienți.

Soluția elegantă este migrarea on-the-fly. Când un utilizator se loghează cu succes:

  1. Verifici dacă hash-ul vechi din baza de date este de tip bcrypt.
  2. Dacă este, verifici parola folosind bcrypt.
  3. Dacă parola e corectă, generezi imediat un hash nou folosind Argon2id.
  4. Salvezi noul hash în baza de date în locul celui vechi.

În felul acesta, în primele 2-3 săptămâni, peste 80% din utilizatorii tăi activi vor fi migrați automat la noul algoritm fără să fi simțit absolut nimic.

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

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