Nu mă refer la generarea unui hash pe partea clientului și apoi stocarea directă în baza de date. Am găsit câteva întrebări cu o temă similară, dar majoritatea acestor răspunsuri presupuneau un scenariu în care parolele erau trimise prin conexiuni necriptate sau hash-ul clientului era stocat direct în baza de date.
(1) Scenariul pe care îl descriu este un pas suplimentar peste fluxurile de lucru existente în care utilizatorul trimite textul simplu prin conexiune https, iar serverul îl hashează cu o sare și stochează hash-ul și sarea în baza de date. Deci, în loc să trimiteți parola reală, dacă un hash este calculat pe partea clientului și trimis la server. Pentru toate scopurile, serverul consideră apoi acest hash inițial al clientului drept parola de text simplu a utilizatorului și apoi rehash cu salt folosind propria sa metodă de hashing așa cum ar face de obicei. În cazul în care serverul înregistrează accidental introducerea parolei utilizatorului (de exemplu: în timpul depanării), parola reală va fi în continuare în siguranță.
(2) De asemenea, dacă hashing-ul pe partea clientului nu este o practică proastă de securitate, ce zici de adăugarea unui șir comun unic la aplicație (de exemplu: numele de domeniu al aplicației) sau a unui șir unic (de exemplu: nume de utilizator) la parola utilizatorului înainte de hashing pentru a se asigura că Hash-ul clientului pentru aceeași parolă ar fi diferit de un hash similar generat de altă aplicație. Contează poziția unui astfel de șir (anexat sau preansat).
O problemă la care mă pot gândi este că serverul nu ar putea impune utilizatorilor o anumită complexitate a parolei. Utilizatorii pot fi în continuare avertizați (sau parolele pot fi respinse) din partea clientului, dar un utilizator poate alege în continuare să-l ocolească și să trimită prin orice șir care are aceeași lungime cu lungimea hash așteptată.
