Ce metodă să utilizați pentru a cripta parolele în baza de date MySQl? [duplicat] (Programare, Php, Mysql, WordPress, Criptare)

Explozie a intrebat.
a intrebat.

Am cercetat cea mai bună metodă de criptare a parolei în baza de date MySQL, dar nu am reușit să identific cea mai bună criptare pentru parole.

  • md5() se spune că este defectă din diverse motive de securitate pe care nu le cunosc, dar este cumva folosită de WordPress. De ce este atât de criticată această funcție?

  • sha1() este doar o altă funcție inspirată de md-serie cu o complexitate computațională mai mare.

  • password() pare a fi sfătuită să fie folosită.

  • și PASSWORD() în MySQl

  • atunci, noua funcție hash() care a intrat în uz în PHP 5.1.2. și în versiunile mai noi

În ce fel este MySQl PASSWORD() diferit de alte funcții php numite mai sus?

Comentarii

  • Vizitați postul pe care @Nikhil Baby îl oferă și citiți password_hash() și password_verify() –  > Por Michael Eugene Yuen.
2 răspunsuri
Binarus

În primul rând, vă rugăm să rețineți că majoritatea oamenilor nu fac criptează (așa cum ați scris) parolele în bazele lor de date. Criptarea, fie ea simetrică sau asimetrică, înseamnă că datele ar putea fi decodate din nou. Criptarea parolelor ar fi un concept foarte prost (cel puțin dacă ar exista o cheie comună pentru toate), deoarece cheile de decriptare ar trebui să fie stocate undeva, iar dacă un atacator ar intra în posesia lor, ar putea decripta imediat toate parolele.

Ceea ce doriți să faceți se numește hashing. Hash-ul unei parole se obține din parolă prin aplicarea unei funcții de hashing la parolă. Punctul cheie aici este că acest proces nu poate fi inversat, adică nu există nicio metodă matematică pentru a obține parola înapoi din hash.

Acestea fiind spuse:

  • MySQL SET PASSWORD și PASSWORD() sunt depreciate. Ele vor fi eliminate în versiunile viitoare ale MySQL. Dacă doriți ca aplicația dvs. să funcționeze cu versiunile viitoare ale MySQL, nu utilizați SET PASSWORD și PASSWORD().

  • MD5 și SHA1 nu sunt cu siguranță calea de urmat; ele sunt considerate rupte.

  • Familia SHA-2 (de exemplu, SHA256, SHA512) este considerată sigură din punct de vedere matematic. Cu toate acestea, are un cost de calcul redus / viteză mare, iar GPU-urile de consum din prezent pot calcula mai multe miliarde de hashes SHA-2 pe secundă. Astfel, pentru hashing-ul parolelor, alte funcții de hashing precum bcrypt, , pbkdf2 sau scrypt (care este preferata mea actuală) sunt adecvate; acestea sunt concepute pentru a fi lente (cât de lente pot fi ajustate, ceea ce reprezintă un mare avantaj în viitor) și (în cazul scrypt) pentru a consuma multă memorie, ceea ce face ca atacurile bazate pe hardware (ASIC, FPGA) să fie mai dificile.

Nu cunosc PHP, dar majoritatea limbajelor au o funcție numită crypt() sau encrypt() sau altele asemănătoare care utilizează funcția crypt() API a sistemului de operare de bază (în Linux: glibc), astfel încât ați putea folosi acest lucru ca punct de plecare, dar numai dacă acesta oferă deja unul dintre algoritmii de hashing lent (ceea ce de cele mai multe ori nu este cazul).

MySQL are o funcție numită ENCRYPT() care utilizează, de asemenea, funcția crypt(), , dar și aceasta este, de asemenea, depreciată. MySQL are, de asemenea, o funcție SHA2() funcție, , dar, după cum s-a menționat mai sus, aceasta ar putea să nu fie suficientă. Din păcate, MySQL (AFAIK) nu oferă o funcție BCRYPT(), , PBKDF2(), , SCRYPT() sau orice altă funcție de hașurare lentă bine cunoscută.

Deoarece ar trebui să utilizați unul dintre algoritmii de hashing lent și deoarece nici sistemul de operare crypt() (în majoritatea cazurilor) și nici MySQL nu oferă niciunul dintre ele, ar trebui să efectuați hashing-ul în aplicația back-end. După cum am spus mai sus, nu cunosc PHP, dar sunt sigur că există o implementare pentru cel puțin un algoritm de hashing lent bine cunoscut (care nu depinde de sistemul de operare/libc-urile de bază). crypt()).

Apropo, nu vor exista diferențe în ceea ce privește rezultatul între diversele implementări ale algoritmilor de hashing. De exemplu, dacă aplicați SHA512 unui șir de caractere folosind limbajul de programare preferat, rezultatul va fi același ca și dacă aplicați SHA512 aceluiași șir de caractere folosind MySQL. Același lucru este valabil și pentru ceilalți algoritmi de hashing, inclusiv pentru cei lenți. Este posibil să existe un performanță diferență de performanță, totuși.

Aceasta înseamnă, în esență, că, dacă acum efectuați hashing-ul în back-end-ul aplicației dumneavoastră, îl puteți face mai târziu în MySQL, de îndată ce MySQL furnizează algoritmul lent de hashing pe care îl utilizați. Puteți trece de la hashing în back-end-ul aplicației la hashing în baza de date fără a fi nevoie să recalculați toate hash-urile stocate și fără a pierde date.

Reguli suplimentare:

  • Nici nu vă gândiți să implementați propriul sistem de autentificare/parolă înainte de a avea complet înțeles toate referințele pe care le-am dat.

  • Dacă din anumite motive sunteți forțat să folosiți un alt algoritm de hashing decât unul lent, folosiți întotdeauna salting, , bineînțeles cu o sare diferită pentru fiecare parolă. În timp ce unii proclamă că acest lucru este inutil, eu nu cred că este așa. Tot va face atacurile mai dificile (în comparație cu hashing-ul fără sare). Dar atacurile împotriva algoritmilor de hashing rapizi, cum ar fi cei din familia SHA-2, indiferent dacă se utilizează sau nu săruri, vor fi în continuare extrem de ușoare și eficiente în comparație cu atacurile împotriva unuia dintre algoritmii de hashing lenți.

În cele din urmă, iată un articol de blog care ar trebui să vă ajute să începeți. Acest lucru vă va da o idee despre ceea ce este important, dar va trebui să faceți cercetări suplimentare (au trecut patru ani de atunci…).

Comentarii

  • Mulțumesc pentru răspuns ,asta căutam. –  > Por Explozie.
  • Un răspuns bun, dar ușor înșelător. Citind răspunsul tău pare că recomanzi SHA brut ca metodă de hashare a parolelor, ceea ce presupun că nu este cazul, deoarece SHA brut, sărat sau nu, nu este bun pentru hasharea parolelor. –  > Por Luke Joshua Park.
  • @LukePark Poate că ar fi trebuit să clarific mai mult faptul că, de fapt, recomand scrypt. Acesta este motivul pentru care am menționat „funcții de hashing mai lente” și „iterații în creștere”. În afară de asta, dacă clubul local de floricultori format din 14 membri și care își găzduiește site-ul web într-un mediu partajat pentru 1 dolar/lună chiar are nevoie de hashing scrypt pentru stocarea parolelor ar putea fi subiectul unor discuții interminabile (probabil, nu pot folosi scrypt chiar dacă sunt dispuși, deoarece CMS-ul lor nu îl oferă). –  > Por Binarus.
  • @Downvoter De ce downvote? Te rog să mă lași să învăț din înțelepciunea ta divină… -.  > Por Binarus.
  • Orice sistem de autentificare, fără excepții, ar trebui să folosească hashing iterativ. Bcrypt și PBKDF2 sunt în mod normal recomandate în locul lui scrypt. Niciodată și niciodată nu ar trebui să se folosească o singură funcție hash, dar răspunsul tău implică faptul că folosirea SHA2 este în regulă. Eu aș corecta acest lucru. –  > Por Luke Joshua Park.
Alejandro Sanchez

Motivul pentru care hash-urile simple, cum ar fi md5 și sha1, nu sunt foarte sigure este că sunt ușor de spart cu puterea de calcul din zilele noastre, ar trebui să folosiți hashing cu sare. [Iată un răspuns excelent de la StackOverflow la întrebarea dvs.] (hash și sare sigure pentru parolele PHP).

WordPress nu mai folosește MD5, WordPress folosește funcția PasswordHash, aici găsiți mai multe informații despre ce face WordPress.