Ce este o sare criptografică “ sare ”?

Motivul pentru care sunt folosite sărurile este că oamenii tind să aleagă aceleași parole, și nu deloc la întâmplare. Multe parole folosite acolo sunt cuvinte reale scurte, pentru a fi ușor de reținut, dar și acest lucru permite un atac.

După cum știți, parolele nu sunt în general stocate în text clar, ci mai degrabă hash. Dacă nu sunteți sigur de scopul unei funcții hash, vă rugăm să citiți mai întâi acest lucru.

Acum, ceea ce pot face atacatorii este să genereze pur și simplu o listă de parole obișnuite și hashurile lor corespunzătoare. introducerea hashurilor pe care un site le-a stocat în tabel va dezvălui parolele atacatorului, dacă sunt folosite parole comune.

A salt este pur și simplu adăugat la faceți o ieșire hash de parolă unică chiar și pentru utilizatori adoptând parole comune . Scopul său este de a face inutilă atacurile bazate pe pre-calcul. În cazul în care parola dvs. este stocată cu o sare unică, atunci orice tabel precomputat cu hash de parolă care vizează hashurile de parolă nesărate sau care vizează un cont cu altă sare nu va ajuta la crăparea parolei contului dvs. O sare lungă generată aleatoriu (folosind /dev/urandom) este de așteptat să fie global unic . Astfel sărurile pot fi folosite pentru a face pre -atacurile de calcul sunt total ineficiente.

Cel mai simplu mod de a combina sarea și parola este pur și simplu să le concatenăm, adică valoarea hash stocată este Hash(salt||password). parola password1 devine acum magic, de ex., 6$dK,3gCA%Jpassword1 ceea ce este puțin probabil să se găsească într-un tabel al unui cracker de parole.

Sarea poate fi stocată complet în spațiul liber din baza de date, lângă valoarea hash. Odată ce atacatorul are baza de date și dorește să găsească parolele, trebuie să genereze tabelul precalculat pentru fiecare sare în mod individual, o operațiune costisitoare.

Un alt mod de a vă ajuta să vă apărați împotriva cracării offline a parolei este să efectuați întinderea parolei, adică. făcând un hash de parolă mai lent de calculat pentru orice persoană, inclusiv serviciul de conectare și crackerele de parole. O metodă utilizată pentru a întinde parolele este realizată prin iterarea funcției hash de multe ori, adică stocarea Hash(Hash(Hash(Hash…(Hash(salt||password)))…).

O altă idee comună legată de sărare se numește piper . Adică, o altă valoare aleatorie concatenată parolei, astfel încât valoarea stocată să fie Hash(pepper||salt||password). Ardeiul nu este apoi deloc stocat . Atât serverul de conectare, cât și crackerul de parole trebuie să forțeze brute valoarea piperului necunoscut, încetinind compararea hash-ului parolelor pentru ambele părți.

Din 2013 până în 2015 un hash de parolă competiția a fost organizată pentru a căuta un algoritm mai bun de întindere a parolelor. Câștigătorul a fost algoritmul Argon2 . Programatorilor li se recomandă să utilizeze Argon2 în loc să implementeze propriul algoritm .

Comentarii

• Deci, în esență, atunci când aveți doar una sau 2 parole stocate în baza de date, utilizarea sării este efectiv inutilă? Ceea ce înțeleg este că acest lucru este util numai atunci când numărul de parole stocate în baza de date nu este mic.
• @AbhinavChoudhury: Nu, se apără împotriva tabelelor curcubeu – adică tabele precalculate pentru un hash specific. Un exemplu: luați o parolă ” password1 „. Dacă nu ‘ t sare, ‘ d stocați HASH (” parola1 „) în baza de date. Acum, dacă un atacator primește înregistrările dvs. și a precalculat HASH (*) pentru toate parolele cu 9 caractere, el poate recupera parola. Dacă ați sărat parola, HASH (‘ somesaltforyou ‘ || ‘ parola1 ‘) NU va fi în tabelul curcubeu al atacatorilor (deoarece ‘ are mai mult de 9 caractere).
• ” Sarea poate fi stocată complet în spațiul liber din baza de date, lângă valoarea hash ” – – această parte nu a avut niciodată sens pentru mine; Mă întrebam dacă puteți extinde acest lucru
• Scopul sării este să vă asigurați că hash-ul nu se găsește într-un tabel precomputat. Trebuie stocat pentru a verifica parola (în caz contrar, ‘ sa ” piper „). Sarea nu ar trebui să fie ” secret „, doar pentru a face parola unică. Aceasta înseamnă, desigur, că fiecare parolă stocată trebuie să aibă propria sa sare, unică (și aleatorie).

Puteți să mă ajutați să înțeleg ce este o „sare” criptografică?

În contextul parolei creație, o „sare” reprezintă date (aleatorii sau altele) adăugate la o funcție hash pentru a face ca ieșirea hash a unei parole să fie mai greu de spart.

Când ar putea fi necesar să-l folosesc?

Întotdeauna.

De ce ar trebui sau nu ar trebui să-l folosesc?

Ar trebui să utilizați întotdeauna o valoare de sare cu funcțiile dvs. hash, din motivele explicate mai jos.

În general, este adevărat că oamenii aleg parole slabe și este cu siguranță adevărat că există gigaocteți de tabele curcubeu disponibile public pline de valori hash care le reprezintă. Deci, atunci când cineva creează un cont în serviciul dvs. și selectează o parolă pentru a-și asigura identitatea, puteți paria de obicei parola pe care o aleg: 1) comună, 2) nesigură și 3) disponibilă pentru referințe încrucișate în tabelele de căutare.

De exemplu, parola Nowayin1 atunci când hash prin MD5 este 6f367d65bc74b88e21fb9959487ffa3a și, evident, nu este o alegere bună. Chiar dacă poate arăta bine (și nu este „t), faptul că hash-ul MD5 al parolei apare în bazele de date deschise nu îl valorează.

Dar asta este doar MD5 pe 128 de biți. mai puternic, cum ar fi SHA1 (160 biți) sau chiar Whirlpool (512 biți)?

Aceeași problemă.

De exemplu, Cuvântul P @ $$ cu SHA1 este 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 și

1qazXSW @ trunchiată cu Whirlpool este 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .

Problema rădăcină cu toate aceste parole și cu miliarde mai multe asemănătoare este faptul că hashurile lor utilizate în mod obișnuit au devenit cunoscute.

O parolă salt modifică acest lucru.

Dacă s-a adăugat o valoare aleatorie (sarea) la parola selectată de utilizator, atunci hasha SHA1 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 nu va mai dezvălui P @ ca parolă a utilizatorului, deoarece valoarea hash din tabelul curcubeu nu s-ar mai potrivi cu ea.

Și nu ar dura mult. O mică valoare aleatorie de 16 biți, de exemplu, ar produce 65.536 de variante ale fiecărei valori hash în tabelele de căutare. Deci, o bază de date de 15 miliarde de intrări ar avea acum nevoie de peste 983 miliarde de hashuri în ea pentru a contabiliza sarea.

Deci, acesta este punctul de a sări hashurile dvs., pentru a contracara tabelele de căutare și curcubeu. „Nu-ți agăța pălăria pe un hash sărat, deoarece hackerii nu au pierdut mult timp folosind tabele curcubeu pentru a-ți afla parolele.

Vor folosi un sistem de cluster de 25 de GPU-uri cu cinci servere care rulează Hashcat, care poate arde 350 de miliarde de ghiciuri pe secundă pentru fiecare parolă imaginabilă de opt caractere care conține litere majuscule și minuscule, cifre și caractere speciale, doar sub sase ore. (Și asta s-a întors în 2012.)

Tehnici precum întinderea tastelor care fac ca hash-urile să ruleze mai lent pot fi folosite pentru a compensa viteza unui astfel de hardware, făcând atacurile de dicționar și de forță brută prea lente pentru a fi utile. , dar hardware-ul devine din ce în ce mai rapid.

ACTUALIZARE 2018:

Cele mai bune practici actuale includ marcarea în siguranță a parolelor dvs. cu Argon2i (preferat peste scrypt), o funcție de memorie care este foarte rezistent la FPGA-uri, GPU-uri multiplecore și module ASIC dedicate folosite pentru a sparge cu ușurință expresii de trecere neintinse. În implementarea PHP7 a Argon2, sarea este tratată intern pentru dvs.

Voi încerca să răspund la o parte din întrebarea dvs. care a fost neglijată până acum:

când ar putea fi necesar să-l folosesc și de ce ar trebui / nu ar trebui să-l folosesc.

Răspunsul scurt este că, ca amator, nu ar trebui să utilizați criptografia la un nivel care necesită gestionarea directă a sărurilor.

De exemplu, bcrypt algoritmul de eliminare a parolei utilizează săruri intern. Dar nu expune acest fapt dezvoltatorilor care îl folosesc – pur și simplu treceți parola către bcrypt (și opțional, un parametru care stabilește „nivelul” de efort CPU „necesar pentru a genera hash) și returnează hash. Când trebuie să validați dacă o parolă este corectă, treceți bcrypt atât parola, cât și hashul generat anterior. Va indica dacă parola a fost sau nu cea utilizată pentru a genera hash-ul.

Nu nu luați sfaturile date aici și încercați să hash-vă propriile parole folosind o sare. Este un detaliu de implementare la nivel scăzut și, dacă vă aflați lucrând la un nivel în care sunt necesare astfel de lucruri, lucrați la un nivel de abstractizare mult prea scăzut. Criptografia este foarte dificil de realizat corect, iar Internetul este absolut plin de dezvoltatori bine intenționați, „scheme nesecurizate complet de securizare a parolelor cultivate la domiciliu”.

O sare este o numărul aleatoriu necesar pentru a accesa datele criptate, împreună cu parola.

Dacă un atacator nu cunoaște parola și încearcă să o ghicească cu un atac cu forță brută, atunci fiecare parolă pe care o încearcă trebuie încercat cu fiecare valoare de sare.

Deci, pentru o sare de un bit (0 sau 1), aceasta face criptarea de două ori mai greu de rupt în acest fel. O sare de doi biți îl face de patru ori mai greu, o sare de trei biți de opt ori mai greu etc. Vă puteți imagina cât de dificil este să spargeți parolele cu criptare care utilizează o sare de 32 de biți!

Comentarii

• Nu. Sarea este de obicei presupusă a fi cunoscută de atacator. În acest caz, după un prag scăzut, sarea nu îmbunătățește securitatea.
• ” Sarea este de obicei presupusă a fi cunoscută de atacator ” – > Cine presupune acest lucru?
• @Mike: Cine? Cineva spune ” Ar trebui să presupuiți întotdeauna că atacatorul știe sarea. „. Persoanele din altă pagină spun ” Sărurile sunt publice ” și mai târziu spune ” sărurile sunt cunoscute, deoarece ‘ este utilizarea standard a industriei a cuvântului sare. ” Altul spune ” sarea este cunoscută publicului sau cel puțin ar trebui tratată ca publică cunoștințe. „.