Viteza poate fi un avantaj dintr-un motiv și un dezavantaj pentru altul.
Când vine vorba de securitatea parolei, cerințele scăzute de CPU/memorie ale unui hash criptografic aduce un dezavantaj, și anume că, dacă înregistrările sau baza de date sunt expuse sau piratate, un atacator are o muncă minimă de făcut pentru a forța brutal acele hashuri într-un text simplu. parola.
Acest lucru se datorează faptului că parolele sunt de obicei scurte și au mai puțină entropie decât securitatea preimagine a funcției hash. Dacă parolele sunt uriașe și aleatorii, să spunem 32 de litere și numere aleatorii, atunci o singură iterație rapidă a funcției hash este mai mult decât suficientă.
Pentru securitate, doriți ca o „funcție de hashing a parolei” să ia cât mai mult timp (resurse de calcul) și memorie posibil pentru a încetini atacurile în bloc. Cu toate acestea, acest lucru devine un dezavantaj pentru server, care va compara un hash cu valoarea bazei de date, deoarece în majoritatea cazurilor acel server trebuie să calculeze hash-ul de la o parolă furnizată de utilizator.
Un atacator poate exploata acest dezavantaj consumând cantități mari de resurse prin încercări coordonate de conectare în masă a numelor de utilizator cunoscute sau așteptate, efectiv un atac de refuz al serviciului cu lățime de bandă redusă, serverul este atât de ocupat să țină pasul cu încercările de conectare false încât utilizatorii reali nu se pot autentifica.Acest lucru poate fi atenuat prin limitarea încercărilor de acces pe adresă IP, pe nume de utilizator și, de asemenea, prin adăugarea unei întârzieri înainte ca un eșec de conectare să fie afișat. Dacă utilizatorul nu există, serverul nu ar trebui să trimită parola, ci ar trebui să returneze o eroare cu o întârziere adecvată, ca și cum utilizatorul ar fi existat, astfel încât un atacator să nu poată deduce prezența numelor de utilizator în baza de date.
PBKDF2 este un hash de parolă extrem de comun și, în esență, utilizează în mod obișnuit HMAC, așa că ceva de genul 40000 de runde de PBKDF2-HMAC-SHA256 poate dura de fapt de aproximativ 80000 de ori mai mult decât o singură iterație hash. Dacă serverul putea anterior să efectueze 4 miliarde de iterații hash pe secundă, acum s-ar putea să poată face doar 50000 de hash-uri de PBKDF2 înainte de a-și satura complet CPU. Dacă nu doriți să fie alocate mai mult de 10% din resurse pentru verificarea parolei, aceasta ar trebui să fie redusă la 5000 de încercări de autentificare pe secundă... ceea ce poate suna ca mult, dar câte persoane credeți că se conectează la ceva de genul Gmail, Lastpass sau Salesforce în jurul orei 9:00 în zilele de luni?
Trebuie să existe o configurație echilibrată și suficient hardware pentru a gestiona toate conectările utilizatorilor, chiar și în condiții de sarcină grea, fără o întârziere vizibilă pentru acești utilizatori și pentru a împiedica actorii răi să refuze serviciul acelor utilizatori. Puterea hash-ului parolei poate trebui, de asemenea, să se schimbe în timp, pe măsură ce resursele atacatorilor cresc, modelele de amenințări se schimbă etc. Costul daunelor reputației poate fi de multe ori mai mare decât costul hardware-ului pentru a efectua hash-uri de parole foarte scumpe.
Există și alte situații în care a fi rapid este un dezavantaj? Din capul meu nu mă pot gândi la niciuna, funcțiile hash sunt de obicei folosite ca parte a unei scheme, cum ar fi semnăturile digitale, de exemplu, cu un algoritm asimetric costisitor din punct de vedere computațional implicat, securitatea în acest caz vine din dimensiunea hash-ului și puterea efectivă a cheii de semnare, nu viteza hash-ului.
