Puncte:0

Este posibilă validarea puterii parolei pe partea de server cu hashingul parolei pe partea clientului?

drapel in

Să presupunem că doresc să configurez o strategie clasică de autentificare a numelui de utilizator și a parolei pe un server. Toate comunicațiile sunt criptate prin TLS. Dar, în mod ideal, tot nu vreau ca serverul să poată citi parolele în text simplu, chiar și temporar. În acest scop, clientul ar putea trimite parola care este hashing și sărată cu o cheie (pentru simplitate, să presupunem că este numele de utilizator). Să numim asta a derivat parola. Serverul ar hashează apoi, la rândul său, parola derivată folosind un algoritm precum Bcrypt sau PBKDF2 și o va stoca pentru cereri viitoare.

Până acum, nimic din toate acestea nu este nou și există o mulțime de discuții despre acest subiect. Dar ceea ce nu pot găsi în aceste discuții este cum să efectuez validarea pe partea serverului putere al text simplu parola in discutie? Orice validare a puterii pe partea clientului poate fi ocolită sau o aplicație client ar putea avea o eroare care validează insuficient puterea, prin urmare, validarea puterii ar trebui să fie făcută pe server. Dar, în același timp, nu vreau ca serverul să aibă acces la parola de text simplu.

Deci întrebarea mea este, sunt acele 2 cerințe care se exclud reciproc sau există vreo modalitate de a îndeplini ambele cerințe? Validarea puterii ar putea fi făcută pe baza parolei derivate? Cel puțin, este posibil să se verifice lungimea parolei în text simplu folosind parola derivată pentru a preveni înregistrarea cu, de exemplu, o parolă goală? Sau, în calitate de proprietar de proiect, trebuie doar să accept că unii utilizatori pot ocoli validarea la nivelul clientului și nu-și asuma responsabilitatea dacă conturile lor sunt compromise ca urmare a ocolirii validării puterii clientului?

Îmi dau seama că s-ar putea folosi o strategie mixtă, în care o parolă este trimisă de la un client în formă de text simplu doar în timpul înregistrării/resetarea parolei și în formă sărată, hashed pentru orice solicitare ulterioară. Aceasta este o îmbunătățire față de trimiterea parolei în text simplu tot timpul, dar încă nu satisface cerința de a nu expune niciodată parola în text simplu la server.

Puncte:3
drapel ca

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.

arslancharyev31 avatar
drapel in
„Faceți asta pur și simplu repetând procedura de hashing din partea clientului cu aceste intrări din partea serverului și verificați egalitatea.” - Nu m-am gândit la această abordare, dar acum văd cum poate fi folosită eficient pentru a preveni înregistrarea parolelor dintr-o listă de cazuri speciale (cum ar fi șirul gol). Mulțumesc.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.