Dacă am hash parole înainte de a le stoca în baza de date, este suficient pentru a preveni ca acestea să fie recuperate de către cineva?
Trebuie să subliniez faptul că aceasta se referă doar la preluare direct din baza de date, și nu orice alt tip de atac, cum ar fi bruteforcing pagina de conectare a aplicației, keylogger pe client, și, desigur, rubberhose criptanaliza (sau, în zilele noastre, ar trebui să ne numim "Ciocolată Criptanaliza").
Desigur, orice formă de hash nu va preveni aceste atacuri.
Notă: Acest răspuns a fost scris în 2013. Multe lucruri s-au schimbat în următorii ani, ceea ce înseamnă că acest răspuns ar trebui văzut în primul rând ca și cum cele mai bune practici utilizate pentru a fi în 2013.
Teoria
Avem nevoie pentru a hash parole ca o a doua linie de apărare. Un server care poate autentifica utilizatorii conține în mod obligatoriu, undeva în măruntaiele sale, unele date care pot fi utilizate pentru a validate o parolă. Un sistem foarte simplu-ar stoca parolele în sine, și de validare ar fi o simplă comparație. Dar dacă un inamic străin au fost pentru a obține o simplă privire la conținutul fișierului sau tabel de bază de date care conține parolele, apoi că atacatorul ar învăța o mulțime. Din păcate, astfel de parțială, read-only încălcări apar în practică (a pierdut bandă de rezervă, o scoase din uz, dar nu a sters-out hard disk, pe o perioada de un atac SQL injection-posibilitățile sunt numeroase). A se vedea acest post pe blog pentru o discuție detaliată. Deoarece în general conținutul unui server care poate valida parolele sunt în mod necesar suficientă pentru a într-adevăr valida parole, un atacator care a obținut un read-only imagine de server este în poziția de a face un offline dicționar atac: el încearcă potențial parole, până când un meci este găsit. Acest lucru este inevitabil. Astfel ne dorim să facem acest tip de atac la fel de greu ca posibil. Instrumentele noastre sunt următoarele:
- Funcții hash criptografice: acestea sunt fascinante obiecte matematice care toată lumea poate calcula în mod eficient, și totuși nimeni nu știe cum să le inversa. Acest lucru pare de bun pentru problema noastră - server ar putea stoca o hash de o parolă, atunci când a prezentat cu un presupus parola, serverul trebuie să discutăm pentru a vedea dacă acesta primește aceeași valoare; și totuși, știind hash nu dezvăluie parola în sine.
- Săruri: printre avantajele atacatorul peste defender este parallelism. Atacatorul, de obicei, apucă o listă întreagă de parole hash, și este interesat de rupere cât mai multe dintre ele ca posibil. El ar putea încerca să atace în mai multe paralele. De exemplu, atacatorul poate lua în considerare o potențială parola, hash, și apoi compara valoarea cu 100 de parole hash; acest lucru înseamnă că atacatorul shares la cost de hashing pe mai multe atacat parole. Un similare optimizarea este precomputed tables, inclusiv tabele curcubeu; acest lucru este încă paralelism, cu un spațiu-timp de schimbare de coordonate. Caracteristica comună a tuturor atacurilor care folosesc paralelismul este că ei lucrează pe mai multe parole care au fost prelucrate cu exact același hash function. Sărare este despre utilizarea nu one funcție hash, dar e un mulțime de distincte hash functions_; în mod ideal, fiecare exemplu de parola hash ar trebui să își folosească propria funcție hash. Un salt este un mod de a selecta o anumită funcție hash printre o mare familie de funcții hash. Aplicate în mod corespunzător de săruri va dejuca complet paralel atacuri (inclusiv tabele curcubeu).
- Lentoarea: computerele devin mai repede de-a lungul timpului (Gordon Moore, co-fondatorul Intel, a teoretizat-o în celebrul său legea). Creierul uman nu. Acest lucru înseamnă că atacatorii pot "încercați" mai mult și mai mult potențialul de parole ca anii trec, iar utilizatorii nu pot să vă amintiți mai multe parole complexe (sau refuză categoric să). Pentru a contracara această tendință, putem face hashing inherently slow prin definirea funcție hash pentru a folosi o mulțime de interne iterații (mii, poate milioane). Avem câteva standard de funcții hash criptografice; cele mai cunoscute sunt MD5 și SHA familie. Construirea unui secure hash funcția de operațiuni elementare este departe de a fi ușoară. Când criptografi doresc să fac asta, ei cred că greu, apoi mai greu, și de a organiza un turneu în cazul în care funcțiile lupta reciproc cu înverșunare. Când sute de criptografi ros și și-a zgâriat și lovit la o funcție pentru mai mulți ani și nu a găsit nimic rău de spus despre el, atunci ei încep să recunosc că, poate ca funcție specifică ar putea fi considerate mai mult sau mai puțin sigure. Aceasta este doar ceea ce s-a întâmplat în SHA-3 concurs. Am have pentru a utiliza acest mod de proiectare funcție hash pentru că știm că nici o modalitate mai bună. Din punct de vedere matematic, nu știm sigur dacă funcțiile hash de fapt există; trebuie "candidații" (ca's diferența dintre "nu poate fi spart" și "nimeni în lume nu știe cum să-l rupe"). O bază de funcție hash, chiar dacă sigure as un hash function, nu este adecvată pentru hash parola, deoarece:
- este nesărat, permițând paralel atacuri (tabele curcubeu pentru MD5 sau SHA-1 pot fi obținute gratuit, nu aveți nevoie chiar de a recalcula le tine);
- este mult prea repede, și devine mai rapid cu progresele tehnologice. Cu un GPU recent (de exemplu, off-the-shelf produs de consum care toată lumea poate cumpăra), hashing rata este luată în calcul în miliarde de parole pe secundă. Deci am nevoie de ceva mai bun. Așa se întâmplă că pălmuirea împreună o funcție hash și sare, și repetăm, nu este mai ușor de făcut decât proiectarea o funcție hash-cel puțin, dacă doriți ca rezultatul să fie sigure. Acolo din nou, trebuie să se bazeze pe standard construcții care au supraviețuit atacului continuu vindicative criptografi.
Buna Parola Hash Funcții
PBKDF2
PBKDF2 vine de la PKCS#5. Este parametrizată cu o repetare conta (un număr întreg, cel puțin 1, fără limită superioară), o sare (un arbitrar secvență de octeți, fără constrângere pe lungime), o ieșire necesare lungime (PBKDF2 poate genera o ieșire de configurabil lungime), și un "de fond al sistemului PRF". În practică, PBKDF2 este întotdeauna folosit cu HMAC, care este în sine o construcție construit peste un fond al sistemului funcție hash. Deci, atunci când spunem "PBKDF2 cu SHA-1", ar însemna, de fapt, "PBKDF2 cu HMAC cu SHA-1". Avantajele PBKDF2:
- A fost specificat pentru o lungă perioadă de timp, pare neatinsă de acum.
- Este deja puse în aplicare în diverse framework (de exemplu, este prevăzută cu .NET).
- Extrem de configurabil (deși unele implementări nu permite să alegeți funcție hash, de exemplu, cea din .NET este pentru SHA-1).
- A primit NIST binecuvântările (modulo diferența între dispersie și de derivare cheie; a se vedea mai târziu).
- Configurabil de ieșire lungime (din nou, a se vedea mai târziu). Dezavantaje ale PBKDF2:
- CPU-intensive numai, astfel cedat la mare optimizare cu GPU (defender este un server de bază care face generic lucruri, de exemplu un PC, dar atacatorul poate cheltui bugetul său pe mai mult de hardware specializat, care va da un avantaj).
- Tu încă mai au pentru a gestiona parametrii te (sare de generare și stocare, repetare conta codare...). Există o standard de codare pentru PBKDF2 parametri, dar se folosește ASN.1 deci, cei mai mulți oameni vor evita, daca se poate (ASN.1 poate fi dificil să se ocupe de non-expert).
bcrypt
bcrypt a fost proiectat prin reutilizarea și extinderea elemente ale unui cifru bloc numit Blowfish. Repetare număr este o putere a lui doi, ceea ce este un pic mai configurabil decat PBKDF2, dar suficient deci, cu toate acestea. Aceasta este esența parola hash mecanism în OpenBSD sistem de operare. Avantajele bcrypt:
- Multe implementări disponibile în diferite limbi (a se vedea link-uri la sfârșitul pagina de Wikipedia).
- Mai rezistente la GPU; acest lucru se datorează detalii de design interior. La bcrypt autori făcut-o atât de voluntar: refolosite Blowfish pentru Blowfish s-a bazat pe un RAM internă de masă, care este în mod constant accesate și modificate de-a lungul prelucrare. Acest lucru face viața mult mai greu pentru oricine dorește să accelereze bcrypt cu un GPU (GPU nu sunt bun la a face o mulțime de memorie accesează în paralel). A se vedea aici pentru o discuție.
- Ieșire Standard de codare care include sare, repetare conta și de ieșire ca un simplu pentru a stoca caractere șir de caractere imprimabile. Dezavantaje ale bcrypt:
- Mărimea de ieșire este fix: 192 bits.
- În timp ce bcrypt este bun la zădărnicirea GPU, acesta poate fi încă bine optimizat cu FPGA: modern FPGA-uri au o mulțime de mici încorporate RAM blocuri, care sunt foarte convenabil pentru a rula mai multe bcrypt implementări în paralel într-un singur cip. Acesta a fost făcut.
- Parola de intrare dimensiunea este limitată la 51 de caractere. În scopul de a gestiona mai parolele, trebuie să combina bcrypt cu o funcție hash (hash parola și apoi utilizați valoarea hash ca "parola" pentru bcrypt). Combinarea cryptographic primitives este cunoscut a fi periculoase (a se vedea mai sus), astfel încât astfel de jocuri nu poate fi recomandat pe o bază generală.
scrypt
scrypt este o mult mai nou de construcție (conceput în 2009), care se bazează pe PBKDF2 și un stream cipher numit Salsa20/8, dar acestea sunt doar instrumente în jurul valorii de miezul puterea de scrypt, care este RAM. scrypt a fost proiectat pentru a folosi în mod inerent o mulțime de RAM (se generează niște pseudo-aleatoare bytes, apoi în mod repetat să le citiți într-o secvență pseudo-aleatorie). "o Mulțime de RAM" este ceva care este greu de a face paralele. O bază PC-ul este bun la RAM acces, și nu va încerca să citească zeci de independenți RAM bytes simultan. Un atacator cu un GPU sau un FPGA va dori să facă asta, și veți găsi că este dificil. Avantajele scrypt:
- Un PC, adică exact ceea ce defender va folosi atunci când hashing parole, este cea mai eficientă platformă (sau aproape suficient) pentru calcul scrypt. Atacatorul nu mai primește un impuls de a petrece său de dolari pe GPU sau FPGA.
- O modalitate mai mult pentru a regla funcția: dimensiunea memoriei. Dezavantaje de scrypt:
- Tot noi (propria mea regulă de degetul mare este să așteptați cel puțin 5 ani de expunere generala, deci nu scrypt pentru producție până în 2014 - dar, desigur, cel mai bine este dacă other people încerca scrypt în producție, pentru că acest lucru oferă un plus de expunere).
- Nu la fel de multe disponibile, gata de utilizare implementări pentru diferite limbi.
- Clar dacă CPU / RAM mix este optimă. Pentru fiecare dintre pseudo-aleatoare RAM accesează, scrypt încă calculează o funcție hash. Cache-ul va fi de aproximativ 200 de cicluri de ceas, o SHA-256 invocarea este de aproape de 1000. Nu poate fi loc de îmbunătățiri.
- Încă un alt parametru pentru a configura: dimensiunea memoriei.
OpenPGP Reiterat Și Sărate S2K
Am citat aceasta pentru că vă va folosi dacă faci bazate pe parolă fișier de criptare cu GnuPG. Acest instrument urmează formatul OpenPGP, care definește propria parola hash funcții, numit "Simplu E2K", "Sărate E2K" și "Reiterat și Sărate S2K". Numai cel de-al treilea poate fi considerat "bun" în contextul de acest răspuns. Acesta este definit ca hash de un foarte lung șir (configurabil, până la aproximativ 65 mb) constând din repetarea de un octet 8-sare și parola. Cât de departe merg lucrurile astea, OpenPGP's a Reiterat Și Sărate S2K este decent; acesta poate fi considerat ca fiind similar cu PBKDF2, cu mai puțin de configurabilitate. Foarte rar vei întâlni în afara OpenPGP, ca un stand-alone funcție.
Unix "crypt"
Recent sistemele Unix-like (de exemplu, Linux), pentru validarea parole de utilizator, utilizați reiterat și sărate variante de crypt() funcția bazat pe bun funcții hash, cu mii de iterații. Acest lucru este destul de bună. Unele sisteme pot utiliza, de asemenea, bcrypt dll, care este mai bine. Cripta vechi (funcția), bazat pe DES cifru bloc, nu este destul de bun:
- Este lent în software-ul, dar rapid în hardware, și pot fi făcute rapid în software-ul, dar numai atunci când calcul mai multe cazuri în paralel (tehnică cunoscută sub numele de AUDIO sau "bitslicing"). Astfel, atacatorul este un avantaj.
- Este încă destul de rapid, cu doar 25 de iterații.
- Are un 12-bit sare, ceea ce înseamnă că sare de reutilizare va avea loc destul de des.
- Se trunchiază parole de 8 caractere (caractere dincolo de cea de-a opta sunt ignorate) și, de asemenea, picături superioare pic de fiecare personaj (deci sunt mai mult sau mai puțin blocat cu ASCII). Dar cele mai recente variante, care sunt active în mod implicit, va fi bine.
Bad Password Hash Funcții
Despre orice altceva, în special în aproape fiecare casă metodă care oamenii necontenit inventa. Pentru unii motiv, mulți dezvoltatori să insiste pe proiectarea funcția de ei înșiși, și par să presupunem că "sigur criptografice design" inseamna "arunca împreună orice fel de criptografic sau non-criptografice operațiune care poate fi considerat". A se vedea această întrebare pentru un exemplu. Principiul de bază pare a fi faptul că complexitatea mare de rezultate extrem de încurcat de instruire va ameți atacatori. În practică, însă, el însuși dezvoltator va fi mult mai confuz de propria sa creație decât atacatorul. Complexitatea este rău. Casă este rău. Nou este rău. Dacă îți amintești, tu'll evita 99% din problemele legate de hash parola, sau criptografie, sau chiar de securitate, în general. Hash parola în sistemele de operare Windows folosit pentru a fi mindbogglingly îngrozitor și acum este doar groaznic (nesărat, non-a reiterat MD4).
Cheie Derivare
Până acum, am considerat întrebarea de hashing passwords. Aproape problema este despre transformarea o parolă într-o cheie simetrică, care poate fi folosit pentru criptare; acest lucru este numit de derivare cheie și este primul lucru pe care îl faci atunci când "cripta un fișier cu o parola". Este posibil să se facă contrived exemple de hash parola funcții care sunt sigure pentru scopul de a stoca o validare parola token, dar teribil atunci când vine vorba de generatoare de chei simetrice; și reciproca este la fel de posibil. Dar aceste exemple sunt foarte "artificial". Pentru practical funcții cum ar fi cea descrisă mai sus:
- Ieșire de o parola hash funcție este acceptabil ca o cheie simetrică, după posibilă trunchiere la dimensiunea dorită.
- O Cheie de Derivare a Funcției poate servi ca o parola hash funcție de cât de mult "derivate cheie" este suficient de lung pentru a evita "generic preimages" (atacatorul este doar noroc și găsește o parola care produce aceeași ieșire). O producție de mai mult de 100 de bucăți sau așa va fi suficient. Într-adevăr, PBKDF2 și scrypt sunt KDF, nu parola hash function -- și NIST "aprobă" de PBKDF2 ca un KDF, nu în mod explicit ca o parolă hasher (dar este posibil, cu doar un minut o cantitate de ipocrizie, de a citi NIST's proză într-un mod care pare să spună că PBKDF2 este bun pentru hashing parole). În schimb, bcrypt dll este de fapt o cifru bloc (cea mai mare parte a parolei de prelucrare este "cheie programul"), care este apoi utilizat în CTR mode pentru a produce trei blocuri (de exemplu, 192 de biți) de pseudo-aleatoare de ieșire, făcându-l un fel de funcție hash. bcrypt dll poate fi transformat într-un KDF cu o mică intervenție chirurgicală, cu ajutorul cifru bloc în modul CTR pentru mai multe blocuri. Dar, ca de obicei, nu putem recomanda o astfel de casă se transformă. Din fericire, 192 biți sunt deja mai mult decât suficient pentru cele mai multe scopuri (de exemplu, criptare simetrică cu GCM sau EAX are nevoie doar de o cheie de 128 de biți).
Diverse Subiecte
Cum de multe iterații ?
Cât mai mult posibil ! Acest sărate și lente hash este o arms race între atacator și apărător. Utilizați mai multe iterații pentru a face hash de o parola mai greu pentru everybody. Pentru a îmbunătăți securitatea, ar trebui să setați ca număr la fel de mare ca tine poate tolera pe server, având în vedere sarcinile pe care server-ul dvs. trebuie să în caz contrar îndeplini. Mai mare este mai bine.
Coliziuni și MD5
MD5 este broken: este de calcul ușor de a găsi o mulțime de perechi de intrări distincte care hash la aceeași valoare. Acestea sunt numite collisions. Cu toate acestea, coliziunile nu sunt o problemă pentru hash parola. Hash parola necesită o funcție hash pentru a fi rezistente la preimages, nu la coliziuni. Coliziunile sunt pe cale de a găsi perechi de mesaje care dau același randament without restriction, întrucât în hash parola atacatorul trebuie să găsească un mesaj care dă o given ieșire că atacatorul nu lua de a alege. Acest lucru este destul de diferit. Cât de departe ne-am cunoscut, MD5 este încă (aproape) la fel de puternic ca a fost vreodata cu privire la preimages (există o teoretică atac, care este încă foarte mult în ridicol imposibil de a rula în practică). La real problem cu MD5 ca acesta este frecvent utilizat în hash parola este faptul că este foarte rapid, și nesărat. Cu toate acestea, PBKDF2 folosit cu MD5-ar fi robust. Totuși, ar trebui să utilizați SHA-1 și SHA-256 cu PBKDF2, dar pentru Relații Publice. Oamenii se enervează când aud "MD5".
Sare Generație
Principalul și singurul punct de sare este de a fi la fel de unique posibil. Ori de câte ori o valoare sare este reutilizat anywhere, aceasta are potențialul de a ajuta la atacator. De exemplu, dacă utilizați _user degetul pana fel de sare, apoi un atacator (sau mai multe conspiră atacatorii) ar putea găsi că este util de a construi tabele curcubeu care ataca parola hash funcția atunci când sare este "admin" (sau "rădăcină" sau "joe"), pentru că acolo va fi mai multe, eventual, mai multe site-uri din întreaga lume, care va avea un utilizator pe nume "admin". În mod similar, atunci când un utilizator își schimbă parola, de obicei, el își păstrează numele, ceea ce duce la sare de reutilizare. Parolele vechi sunt valoroase obiective, deoarece utilizatorii au obiceiul de a folosi parole în mai multe locuri (ca's cunoscute a fi o idee proastă și promovat ca atare, dar o vor face cu toate acestea, pentru a face viața mai ușoară), și, de asemenea, pentru că oamenii au tendința de a genera parolele lor "în secvența": dacă ai afla că Bob's parola veche este "SuperSecretPassword37", apoi Bob's current parola este probabil "SuperSecretPassword38" sau "SuperSecretPassword39". La ieftin pentru a obține unicitatea este de a utiliza randomness. Dacă ați genera sare ca o secvență de octeți aleatorii din criptografice sigure PRNG că sistemul de operare oferă (
/dev/urandom
,CryptGenRandom ()
...), atunci veți obține sare valorile care vor fi "unic, cu o probabilitate suficient de mare". 16 bytes sunt suficiente, astfel încât nu veți vedea niciodată o sare de coliziune în viața ta, care este nejustificată, dar destul de simplu. UUID sunt o modalitate standard de a genera "unic" valorile. Rețineți că "versiunea 4" UUID folosi doar dezordine (122 aleatoare de biți), asa cum a fost explicat mai sus. O mulțime de programare cadrele oferta de simplu de utilizat funcții pentru a genera UUID la cerere, și ele pot fi folosite ca săruri.Sare Secretul
Săruri nu sunt menite să fie secret; în caz contrar, ne-ar numi keys. Nu need pentru a face săruri publice, dar dacă trebuie să le facă publice (de exemplu, pentru a sprijini client-side hashing), apoi don't vă faceți griji prea mult despre asta. Sărurile sunt acolo pentru unicitate. Strict vorbind, sarea nu este nimic mai mult decât selectarea o anumită funcție hash într-o mare familie de funcții.
"Piper"
Criptografi nu poate să o metaforă; ele must extinde cu mai multe analogii și jocuri de cuvinte rele. ", Presărând" este vorba despre folosirea unui secret de sare, adică o cheie. Dacă utilizați un "piper" parola hash function, apoi comutați la un alt fel de algoritm criptografic; și anume, sunteți de calcul a Message Authentication Code parola. MAC-cheie este "piper". Presărând are sens dacă puteți avea o cheie secretă pe care atacatorul nu va fi capabil să citească. Amintiți-vă că vom folosi hash parola, deoarece considerăm că un atacator ar putea apuca o copie a serverului de baze de date, sau posibil de whole disk de pe server. Un scenariu tipic ar fi un server cu două discuri în RAID 1. Un disc nu (electronica cartofi prajiti - acest lucru se întâmplă o mulțime). Administratorul de sistem înlocuiește discul, oglinda este reconstruit, nu există date este pierdut datorită magia de RAID 1. Deoarece vechiul disc este disfuncțională, administratorul de sistem nu poate șterge cu ușurință conținutul său. El doar a capturilor aruncate înapoi în mare a discului. Atacatorul caută prin saci de gunoi, preia disc, înlocuiește placa, și iată! El are o imagine completă a întregului sistem de server, inclusiv baze de date, fișiere de configurare, fișiere binare, sistemul de operare... full monty, după cum spun Britanicii. Pentru presărând pentru a fi aplicabile, trebuie să fie într-o configurare specială în cazul în care există ceva mai mult decât un PC cu discuri; ai nevoie de un HSM. HSM sunt foarte scumpe, atât în hardware și în procedura operațională. Dar cu o HSM, puteți folosi doar un secret "piper" și procesul de parole cu un simplu HMAC (de exemplu, cu SHA-1 și SHA-256). Acest lucru va fi mult mai eficientă decât bcrypt/PBKDF2/scrypt și greoaie iterații. De asemenea, utilizarea de o HSM va arata extrem de profesionist, atunci când faci un WebTrust de audit.
Client-side hashing
De hashing este (în mod deliberat) scump, s-ar putea face sens, într-un client-server situație, de a valorifica CPU de conectarea clienților. După toate, atunci când 100 de clienți conectați la un singur server, clientii colectiv au o mulțime mai mult de muschi pe server. Pentru a efectua client-side hashing, protocolul de comunicare trebuie să fie îmbunătățită pentru a sprijini trimiterea sare inapoi la client. Acest lucru implică un cost tur-retur, atunci când față de client simplu-trimite-parola-la-server protocol. Acest lucru poate sau nu poate fi ușor pentru a adăuga la cazul dumneavoastră specific. Client-side hashing este dificilă într-un context Web pentru clientul foloseste Javascript, care este destul de anemic pentru CPU-intensive sarcini. În contextul RSP, parola hash neapărat apare pe partea de client.
Concluzie
Utilizarea bcrypt dll. PBKDF2 nu este rău, fie. Dacă utilizați scrypt va fi un "ușor printre primii" cu riscurile pe care le implică această expresie; dar ar fi o mișcare bună pentru progresul științific ("crash dummy" este o foarte onorabilă profesie).
Pentru stocarea parolelor hash-uri, ai nevoie de un algoritm suficient de lent, care brute-force atacuri nu sunt fezabile. Sărare parola va ajuta împotriva curcubeu atacuri, dar nu împotriva brute-force atacuri. Pentru stocarea hash parola, aveți nevoie pentru a utiliza un algoritm special concepute pentru acest scop; cum ar fi:
scrypt
este nou, dar interesant, pentru că nu numai că folosește o variabilă factorului muncă dar, de asemenea, memorie-greu funcții. Acest lucru crește dramatic costul de brute-force atacuri, pentru că ambele rulează de timp și cerințele de memorie sunt crescute.
Parolele stocate într-o bază de date distribuit ca valorile pot fi recuperate fie prin brute-force calcularea hash-uri sau prin utilizarea de tabele curcubeu (care sunt specifice pentru algoritmul folosit).
Un curcubeu de masă este creat ca o serie de pre-valorile calculate pentru un dicționar de fișiere sau mai comun fiecare combinație de un anumit set de caractere [a-z, a-Z, 0-9] fiind un exemplu comun.
În esență, acestea pot accelera cracare de o parolă, permițându-valoarea hash pentru a fi privit în sus în masă, mai degrabă decât necesită atacator pentru a crea hash pentru fiecare parola. Tabele curcubeu pentru parolă comună algoritmi (de exemplu, NTLM, MD5, etc) pot fi găsite on-line, făcându-l destul de simplu pentru a obține acces la volume mari de pe ei.
Există un număr de modalități de a îmbunătăți securitatea de hash-uri stocate în baza de date.
Primul este de a utiliza o per utilizator sare valoare, această valoare este stocat în baza de date, împreună cu parola hash. L't destinat să fie secret, dar este folosit pentru a încetini forța brută procesul și de a face tabele curcubeu imposibil de a utiliza.
Un alt add-on I'am văzut pentru acest lucru este de a adăuga, de asemenea, în ceea ce a fost numit un ardei valoare. Acest lucru a fost doar un alt șir aleator, dar a fost aceeași pentru toți utilizatorii și stocate cu codul de aplicare, spre deosebire de baza de date. teoria de aici este că, în anumite circumstanțe, baza de date poate fi compromisă, dar codul de aplicare nu este, și în aceste cazuri acest lucru ar putea îmbunătăți securitatea. Aceasta nu, cu toate acestea, introduce probleme în cazul în care există mai multe aplicații care utilizează aceeași parolă bază de date.
Un al treilea mijloc de a ajuta îmbunătăți securitatea parolelor este de a utiliza un lent funcția de parolă, asta nu't avea un mare impact asupra utilizatorilor individuali, dar vor masiv încetini un atacator de la fisurare parole preluate din baza de date. Mai multe informații pe această abordare este disponibil aici
Alții au subliniat aici că atacurile brute force nevoie să fie apărat împotriva via săruri, chiar dacă MYSQL încă nu't dat seama de asta. Importanța iterații a fost, de asemenea, menționat, și a fost cunoscut inca din seminale hârtie pe Unix crypt în 1978 de Robert Morris și Ken Thompson. Dar mulți oameni (și dezvoltatorii de asemenea, ca Django!) evident, încă mai cred că forța brută trebuie să aibă o destul de lungă perioadă de timp sau poate fi destul de scump. Nu-i adevărat! Moore's legea și cloud computing-a prins cu noi. Pentru a sparge o parolă alfanumerică de lungime 8 ((26+26+10)^8 = 62^8 = 218,340,105,584,896 = 218 miliarde de combinații) pe un desktop modern mașină durează 5 zile, sau 1 ora daca ai inchiriat o grămadă de Amazon calcula noduri (Cât timp ia să genera de fapt tabele curcubeu? - SE Security) Actualizare: bitcoin hashing capacitate Cel mai puternic organizat hashing capacitatea de pe planetă (cu excepția posibil clasificate sisteme) este bitcoin miniere rețea. În prezent se efectuează SHA-256 hash-uri la un agregat rata de peste 11 Thash/s, adică 11 10^12 hash/s (până în 2016, care este de 1700000 Thash/s - vedea update 4 de mai sus), iar rata a fost în creștere rapid recent (grafice). Minerii sunt de lucru pentru a câștiga estimat de 700.000 de dolari pe săptămână, care miniere randamentele la prețul actual de 14 dolari pe bitcoin (BTC) (grafic), și o rată de 50 BTC produs la fiecare 10 minute. Populare hardware aceste zile include un Radeon HD 5970 GPU, fiecare dintre care are un total de 3200 de procesoare de stream și poate face aproximativ 800 de Mhash/s. Este, de asemenea, econom în consum de energie la aproximativ 2,3 Mhash/Joule. A se vedea Bitcoin mining hardware comparație pentru o mulțime mai multe opțiuni. Se pare că GPU nodurile de pe Amazon's EC2 folosi Gpu-uri Nvidia Tesla, care sunt mai puțin eficiente la hash, și nodurile lor nu sunt't cost-eficiente pentru minerit la ziua de azi's a prețurilor. Acest lucru este de aproximativ de două ori capacitatea de unul 5.5 Thash/s estimare pentru hashing putere a lumii's top 500 de supercomputere combinate, deși, desigur, supercomputere au fost de obicei proiectat pentru virgulă mobilă de performanță, nu de hashing. Ca un curent extremă caz, dacă acest hash capacitate fost redirecționat la încercarea de a sparge parole, de exemplu, în urma unui accident în prețurile bitcoin, ar fi de temut împotriva non-a reiterat parola algoritmi. 8 caractere parole folosind un complet aleatoare a tuturor 94 imprimarea de caractere ar cădea în mai puțin de 10 minute (94^8 / (11 10^12 60) = 9.2). 10 personajul parolele ar lua mai puțin de 57 de zile (94^10 / (11 10^12 3600 24) = 56.7). 10-caracterul superior-inferior caz parolelor alfanumerice (26+26+10 = 62 caractere posibile) ar lua mai mult de o zi (62^10 / (11 10^12 3600 24) = 0.88) chiar dacă este bine randomizate. Dar dacă programatori pur și simplu folosite, de exemplu, o iterație numărul de 2000 ca Thomas sugerează, de mai bine de 10 caractere parolele ar ultimii ani. Deși 8 caractere parolele ar fi ușor de spart, în termen de 13 zile (2000 94^8 / 11 10^12 / 3600 / 24 = 12.8 zile). Vezi de asemenea și:
Parola trebuie să fie întotdeauna distribuit, dar asta nu înseamnă că nu există posibilitatea pentru bruteforce-atacuri. Măsuri suplimentare ar trebui să fie aplicate în ceea ce privește depozitarea și gestionarea utilizatorilor parole. Am foarte recomanda acest articol din Solar Designer despre acest subiect: http://php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users-and-passwords/index.html.
Parolele ar trebui să fie întotdeauna sărate și întins înainte de a le stoca. Practic aceasta implică adăugarea sau anulează un text cu parolă și hashing rezultatul de mai multe ori. Cum pentru hash algos ceva peste și mai presus de MD5 și SHA-1 este în prezent recomandabil - du-te pentru SHA 256 sau 512 (a se vedea http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html)
O parolă bună algoritm hash trebuie să aibă sare și ceva de-a face calculul de parola scump (de obicei repetare conta).
Cele mai bune și cele mai comune, metoda pentru aceasta este PBKDF2. Deși nu este perfect, ar trebui să fie un punct de referință pentru toată lumea:
Am'd doua recomandările pentru PBKDF2. L's cel mai de calcul scump, dar are un standard precis de referință în timpul punerii în aplicare, și-l's bine acceptate.
https://tools.ietf.org/html/rfc2898
Am'd într-adevăr recomanda citirea Colin Percival's de hârtie pe scrypt, totuși. El face o treabă bună de a descrie probleme în a juca aici. Parerea mea este scrypt va arata mai bine și mai bine cu timpul.
http://www.tarsnap.com/scrypt.html
Având implementat un standard nu este nimic, de altfel - nu au fost diferențe între algoritmii descriși în ziare și implementări de referință în ambele bcrypt și scrypt, dacă nu mă înșeală memoria.
În funcție de algoritmul utilizat probabil că răspunsul este nu.
În primul rând, ar trebui să le Sare, acest lucru înseamnă, practic, adaugarea sau anulează un text cu parola.
Atunci ar trebui să utilizați un puternic algoritm (md5 nu't-l taie)
Este interesant de observat că, deși bcrypt și scrypt sunt toate bune soluții pentru parole, cu o favoare pentru acestea din urmă, scrypt pare a fi predispus la cache-calendarul atacuri. Cum a sugerat de aici: http://eprint.iacr.org/2013/525 Catena va fi în siguranță împotriva acest lucru, împreună cu demonstrabile de siguranță și alte câteva caracteristici frumos.
bcrypt este declarat a fi mai lent pe Gpu-uri, ceea ce face ca forța brută mai lent. Cu toate acestea, cu dezvoltarea hardware-ul computerului, ar trebui să se bazeze nu numai pe dificultatea de punere în aplicare un anumit algoritm hash pe hardware special.
Mai degrabă, puteți crește în mod arbitrar de cost pentru bruteforcing un hash folosind "variabilă de muncă/factor de cost" (uneori, de asemenea, numit "runde"), care unele funcții hash sprijin. Printre ei sunt bcrypt și SHA-512.
Glibc's crypt()
funcție permite specificarea runde pentru unii algoritmi de hash. De exemplu, un factor de cost de 100000 pentru SHA-512 face generație (și, prin urmare, forța brută) de hash de aproximativ 4 ori mai lent decât costul factor 08
pentru bcrypt dll. Acest lucru poate fi confirmat de către folosind un hash rezolvarea programul ca hashcat.
Dacă presupunem că la un moment dat parola hash-uri și săruri va fi furat, iar atacatorii vor folosi ASIC hardware pentru bruteforce-le, pur și simplu crește factorul muncă pentru a face încă prea costisitoare pentru ei, în timp ce nu supraîncărca serverul's CPU cu regulate de autentificare a utilizatorului.
Importanța lung și parole aleatorii se aplică cu toate acestea.
Tocmai am scris un blog despre detalii.
tsk tsk, Pentru a încerca să asigure un sistem prin intermediul lent de criptare este un prost's de comision.
De exemplu, să's spun contrariul, avem un hash, și ne dorim pentru a obține parola (și sare dacă este cazul).
Chiar dacă suntem pentru a rula miliarde de hash pe secundă, avem nevoie de o cale pentru a se potrivi valoarea.
De exemplu, să's spun următoarea valoare:
SARE:IT_ISASALT VALOARE:123456 și este hash: 7D371ADDB8862FD3B8320020B0C6B52BEE716A8204CA18B03C9A6B4686EEB610
Deci, vrem să transformăm hash-> SARE+VALOARE.
O modalitate de a realiza acest lucru, se's pentru a cripta o valoare și încercați pentru a compara dacă o parte din valoarea există în dicționar.
De exemplu, am testat-o combinație și am găsit:
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434dCAL ("cal" este un cuvânt care există în dicționarul nostru).
Este dreptul valoare?. Am don't știu, dar ar putea fi, așa că trebuie să stocheze această combinație și să încerce cu restul. L's un proces lent și necesită o mulțime de memorie. Dar chiar și dacă este posibil, am putea găsi o mulțime de false valori. Deci, am putea reduce meciuri din 2^256 de combinații pentru a 2^100 sau mai multe combinații. Pentru aceasta, avem nevoie de o modalitate de a găsi un meci corect. Dacă SAREA nu este trivial, atunci această sarcină ar putea lua o mulțime de timp și resurse, și șansele de succes sunt mai lente.
Acum, las's spun că ar putea genera un nou hash (de exemplu, vom crea un cont fals), astfel încât ne dăm seama de valoarea și hash (dar sare). Aceasta simplifică mult operația, pentru a găsi un meci este egal pentru a găsi un text care se termină cu valoarea noastră (exemplu: 123456). Dar dacă sarea nu este generat ca SARE+VALOARE, dar SALT1+VALOARE+SALT2 sau dacă SARE+VALOARE2 unde VALOARE2 este valoarea modificată cu un algoritm care nu ne't știu.
Acum, las's spun hash nostru este generat după cum urmează:
hash256(SARE+hash256(SARE+VALOARE))
Deci, in concluzie:
Eu folosesc SHA1 aici
def __encrypt(self, plaintext, salt=""):
"""returns the SHA1 hexdigest of a plaintext and salt"""
phrase = hashlib.sha1()
phrase.update("%s--%s" % (plaintext, salt))
return phrase.hexdigest()
def set_password(self, new_password):
"""sets the user's crypted_password"""
#from datetime import datetime, timedelta
import datetime
if not self.salt:
self.salt = self.__encrypt(str(datetime.datetime.now()))
self.crypted_password = self.__encrypt(new_password, self.salt)
def check_password(self, plaintext):
return self.__encrypt(plaintext, self.salt) == self.crypted_password
Mai degrabă decât de sărare parole, cum ar fi acest lucru aș dori că algoritmul este modificat, astfel încât acesta nu't nevoie de sare și a câștigat încă't hash aceeași intrare de două ori la aceeași valoare.