Nu puteți verifica în mod realist puterea oricărei parole care a fost deja hashing atunci când vi s-a trimis. Funcțiile hash sunt funcții unidirecționale prin design, ceea ce înseamnă că nu ar trebui să puteți inversa hash-ul și să obțineți informații semnificative despre intrare.
Cu toate acestea, puteți verifica destul de ușor că parola nu aparține unei liste scurte de parole comune, slabe, cum ar fi șirul gol „”, „abc”, „123”, „parolă”, etc. repetarea procedurii de hashing din partea clientului cu aceste intrări partea serverului și verificarea egalității. Lungimea listei cu astfel de parole slabe va fi limitată de constrângerile de performanță. Deoarece hash-ul trimis de client este sărat, serverul va trebui să construiască din nou această listă pentru fiecare înregistrare și schimbare de parolă.
În consecință, cea mai mare parte a verificărilor corecte ale parolei vor trebui efectuate pe partea clientului, cu condiția ca parola să fie trimisă doar ca valoare hash.
Ideea ta despre o schemă de înregistrare hibridă, în care parola este trimisă ca text simplu către server doar pentru o verificare rapidă, nu este ideală, așa cum ai menționat deja. Pentru început, nu câștigi prea mult dacă clientul trimite o parolă în text simplu, în loc de un hash simplu al aceleiași parole. Majoritatea verificărilor de sănătate care beneficiază de a avea o parolă text simplu, ar putea fi efectuate cu ușurință pe partea clientului. Cea mai mare parte a testării pe partea serverului ar trebui probabil să fie efectuată cel mai bine ca o căutare într-o bază de date de hashe-uri de parole slabe comune (un Rainbow Table).
Acestea fiind spuse, a nu găsi hash-ul într-un astfel de tabel de bază de date nu este o garanție că parola este suficient de puternică.O parolă lungă, care este concatenarea a trei sau patru cuvinte aleatorii dintr-un dicționar, ar putea fi ușor de găsit dacă aveți acces la parola text simplu, dar probabil că nu ar fi o intrare chiar și într-un tabel curcubeu destul de mare.