Există o neînțelegere comună că hash și criptare sunt același lucru. Nu sunt. Hash-ul este ireversibil. Luați exemplul următor:
$ echo-n Password123 | md5sum
42f749ade7f9e195bf475f37a44cafcb-
Trecem șirul „Password123 "către algoritmul MD5 (algo), care efectuează operațiile matematice și returnează hash-ul codificat hexazecimal generat. Singura modalitate de a obține aceeași valoare de ieșire hash este să introduceți algo original. Există conflicte, dar putem discuta mai târziu.
Ieșirea majorității algoritmilor de hash este un șir binar de lungime fixă codificat hexazecimal. Alții, cum ar fi acest exemplu, folosesc șiruri codificate base64 ca ieșire. Rețineți că lungimea este întotdeauna aceeași:
{SHA} uNF8eZRJ8jmr8WTjyocRJPVpe7w =
{SHA} lqdu/Zr6o2dgIER8Up1/7lcUtgw =
{SHA} qYUOwLMlDEuukA5HCT4LR1kQzco =
{SHA} MXZBCpyWJ7TTs1w2kgGJslwNwTg =
{SHA} 2sAPLaUh9Mz0bI + XxKEg7qyABe8=
TL; Dr.
Nu vreau să vorbesc prea mult despre criptare (pentru că chestiile alea sunt pentru cărți), dar este important să poți distinge între șiruri hash și șiruri criptate. Criptarea umple de obicei șirul pentru a satisface o anumită lungime înainte de a avea loc criptarea. De asemenea, necesită o cheie (sau o parolă) pentru a o decripta. Dacă utilizați o parolă criptată, șirul se va modifica în funcție de lungimea intrării. Dacă vedeți o grămadă de parole cifrate, lungimea variază și este posibil să aveți de-a face cu criptarea în loc de hash. AES-256-CBC Exemplu de criptare a șirurilor de caractere și a textului simplu asociat (cheia este "ASDF"):
foobar | U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = foobarfoobar | U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = foobarfoobarfoobar | U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz $ cat parole_criptate U2FsdGVkX19G + KtytNHdj6yH2AVvX26pEmtunS/PRnU = U2FsdGVkX18sPpIvN6nVh68lOUCcb3gR2fKbCCnBxog = U2FsdGVkX1/EOnUt57TCW4Rh0EdNnWX + lDatuQv2xEXXeAeowW0XG/EXJUe9aSUz $ pentru i în `cat encrypted_passwords`; do echo $i | openssl enc -base64 -d -aes-256-cbc -pass pas:asdf; ecou; Gata foobar foobarfoobar foobarfoobarfoobar
Acum probabil că te gândești: probabil că ai dreptate. Cu toate acestea, faptul că materialul critic trebuie să fie accesibil sistemului înseamnă că, în esență, o parolă principală de text simplu se află undeva-fie ca o cheie RSA sau o parolă într-un fișier, încorporată într-o bază de date, codificată hard într-o aplicație sau o parolă undeva în memorie. pfft, nimeni ' nu va folosi asdf ca cheie pentru a cripta parolele utilizatorilor lor '
Utilizați același șir pentru MD5:
foobar | 3858f62230ac3c915f300c664312c63f foobarfoobar | 59faa421729e846dd800dce59943bfc0 foobarfoobarfoobar | 1352aadab322d1a033c27964be0965db
Parola hash este departe de a fi perfectă, de fapt este cam proastă, dar este mai proastă decât criptarea pentru ceea ce încearcă să realizeze. Utilizatorii aleg cerințele minime absolute mai des decât not și pot fi utilizați pe mai multe site-uri. Multe „hack-uri "nu sunt de fapt altceva decât atacuri de reutilizare a acreditărilor. Dacă compromisul inițial este de a folosi criptarea, atunci singurul efort pe care atacatorul trebuie să-l facă este să găsească cheia care decriptează toate parolele. Pentru hash-uri, trebuie să depună cel puțin un efort pentru a le sparge. Atunci când sunt utilizate împreună cu algoritmi moderni, cum ar fi sha512crypt, bcrypt, scrypt sau argon2, valorile hash pot necesita un efort considerabil pentru a fi sparte.
Adăugarea de sare înseamnă adăugarea unui șir la parolă înainte de hash. Sarea fiecărui hash ar trebui să fie unică, de obicei selectată aleatoriu, deoarece punctul este de a face ca aceeași valoare hash "parolă" de text simplu să aibă o valoare diferită de fiecare dată. Acest lucru îngreunează viața unui spargător de parole, deoarece pentru a verifica cuvântul "parola" pentru fiecare dintre cei 1.000 de utilizatori, fiecare utilizator având o SARE unică, trebuie să facă acest lucru de 1.000 de ori-o dată pe utilizator/SARE. Aceasta înseamnă, de asemenea, că nu pot folosi în mod eficient dicționarele precompilate sau tabelele curcubeu (de obicei...), deoarece necesită o sare personalizată.
Site-urile uneori încurcă asta și folosesc sare generică pentru toți utilizatorii; Acest lucru este împotriva scopului.
Iată hash-ul SHA1 cu sare:
b353977827f67a4ae0318f3a9447fae1c13d9d90:b8d18ca |___________________________________________| hash | sare | separator
Textul simplu al acestui hash este „parola ". Valoarea sării sale este "b8d18ca" și este utilizată în API-ul SHA1 ($salt.$pass). Aceasta înseamnă că algoritmul obține textul simplu al parolei, generează sare și îl adaugă în fața textului simplu. Când un site web sau o aplicație încearcă să vă verifice parola în viitor, va lua parola dvs. în text simplu ca intrare, va citi valoarea salt în hash-ul stocat, o va adăuga în fața parolei selectate și va compara hash-ul generat cu hash-ul stocat. Cracking Dacă nu știți că o parte din ea este sare, hash-ul va produce următorul text simplu:
b8d18capassword
Deoarece algoritmul introduce text simplu, sarea și hash generat Valorile pot rămâne transparente pentru utilizator. La cracare, dacă algoritmul este sărat, trebuie să cunoaștem sarea, astfel încât să o putem furniza atunci când generăm textul simplu candidat.
Dacă este implementat corespunzător, sararea poate face ca crăparea să consume mai mult timp. Cu sare aleatorie, forțați Cracker să piardă timp încercând să spargă hash-urile care nu se potrivesc cu sarea. Acest lucru completează aproximativ efortul necesar pentru device_speed/number_of_salts, deoarece trebuie să generăm un candidat pentru fiecare sare. Dacă sarea este statică, atunci operațiile matematice sunt aceleași... speed_of_device/1. Un alt mod de a vedea acest lucru:
Our GTX 980 cracks SHA1 ($salt.$pass) la 3576.8 MH/s sau 3.5 miliarde candidați per second Hashlist-ul nostru conține 1000 săruri unice 3.500.000.000 / 1000 = 3.500.000 candidați per second
Aceasta este cu trei ordine de mărime mai lent, cu o pierdere de 99,9%. Cu sare statică arată așa:
Our GTX 980 cracks SHA1 ($salt.$pass) la 3576,8 MH/s sau 3,5 miliarde candidați pe secundă Hashlist-ul nostru conține 1 sare unică 3.500.000.000 / 1 = 3.500.000.000 candidați per second
Dacă acest lucru nu are sens, continuați să citiți, vom avea o diagramă frumoasă mai târziu...
O altă îmbunătățire comună în comparație cu pur și simplu „hash this plaintext "este „hash this plaintext, apoi hash acel rezultat, apoi hash acel rezultat" repetat de mii de ori. Acest lucru permite programului de spargere a parolelor să facă mii de operațiuni atunci când încercați o singură parolă candidată. Aceasta se numește iterație, buclă sau cost variabil. Unii algoritmi de hash de parolă folosesc runde de iterație codificate hard; Alte Git. Faceți-l configurabil într-o parte a hash-ului în sine. De exemplu, md5crypt () folosește MD5, inclusiv salt, și buclă de exact 1000 de ori. sha512crypt () folosește sha512, include o sare și buclă de un număr configurabil de ori (implicit 5.000).
Iterațiile afectează în principal costul ciclului de calcul al algoritmului de hash, mai degrabă decât utilizarea sa de memorie sau alți factori. Acestea sunt, de asemenea, atacuri importante atunci când proiectarea este optimizată pentru a rezista anumitor tipuri de tipuri de hash, dar acest lucru este prea buruiană pentru a fi discutată aici.
Să aruncăm o privire la câteva exemple pentru a demonstra impactul alegerii algoritmului de hash, fie că este sărat, utilizând mai multe iterații etc. Să presupunem că un atacator a colectat hash-uri de la 1.000 de utilizatori de la un anumit site web infectat și dorește doar să efectueze un simplu atac, testând hash-urile fiecărei parole-143 milioane de parole candidate.
Tipul de hash utilizat de site-ul infectat va avea un impact enorm asupra timpului necesar atacatorului prin atac. Iata un grafic (relativ, aproximativ) de cate secunde dureaza pentru a finaliza atacul, in functie de tipul de hash folosit, unde placa grafica standard:
Ei bine, asta e inutil! Cel mai puternic tip de hash este mult mai lent, dar tipul mai rapid este pur și simplu zdrobit până la nimic. Să încercăm din nou aceeași dimensiune a datelor folosind timpul logaritmic al axei X. Pe măsură ce barele se deplasează de la stânga la dreapta, ele vor crește cu o putere de 10:
Deci câteva puncte importante sunt: atunci când vrei să spargi niște hash-uri de parolă, o singură rundă este mai ușoară decât o rundă multiplă și fără sare decât cu sare. Dimpotrivă, atunci când anumite companii sau site-uri web anunță o încălcare a datelor care conțin date despre utilizatori, a) parola a fost cel mai bine hash, nu doar text simplu; b) ele sunt de preferat sărate, nu doar hash; c) Ar fi mai bine să aibă hash-uri puternice cu mai multe runde de sare care folosesc tot timpul, nu doar o singură rundă.
Înainte de a încerca să spargă un hash de parolă dat, este de seama de cracker să-și dea seama ce algoritm de hash este folosit pentru a-l implementa. Identificarea tipurilor de hash este de obicei simplă, dar nu întotdeauna. Crackerii fac adesea presupuneri informate bazate pe indicii, cum ar fi lungimea și formatul hash-ului. În cele din urmă, singura modalitate de a fi sigur că ghicitul tipului de hash este corect este dacă hash-ul este spart.
Câteva resurse excelente pentru această sarcină sunt disponibile aici și aici și toate arată cum arată valorile hash comune.
Pachetul "hash-identifier" (disponibil aici) este disponibil în Kali Linux, care ajută la identificarea unor tipuri de hash necunoscute.
O coliziune apare atunci când două intrări diferite au ca rezultat aceeași ieșire hash. E rau (evident). În ceea ce privește parolele, acest lucru poate însemna că probabil nu am spart parola dvs. reală, dar din moment ce am găsit o intrare care produce aceeași valoare hash, pot folosi valori de text simplu pentru a păcăli sistemul să creadă că parola este legitimă.
Microsoft Office folosește în protecția documentelor sale un algoritm predispus la conflicte de-a lungul anilor. Nu este neobișnuit să descoperiți mai multe conflicte pentru un singur hash, toate acestea deblocând documentul.
Odată ce se găsește un conflict, algoritmul este practic distrus. Dacă se întâmplă o dată, statistic vorbind, este foarte probabil să se întâmple din nou. Singurul lucru care ne împiedică este timpul și puterea de procesare. Pe măsură ce algoritmii devin mai robuști, generarea algoritmilor candidați și compararea ieșirilor hash pentru a le căuta necesită mai multă putere și timp. Drept urmare, designerii devin din ce în ce mai buni la crearea de algoritmi care sunt mai puțin predispuși la conflicte.