SHA1 vs MD5 vs SHA256: którego użyć do logowania PHP?


133

Robię logowanie php i próbuję zdecydować, czy użyć SHA1, Md5 lub SHA256, o którym przeczytałem w innym artykule o przepływie stosów. Czy któryś z nich jest bezpieczniejszy od innych? Czy w przypadku SHA1 / 256 nadal używam soli?

Czy jest to również bezpieczny sposób przechowywania hasła jako skrótu w mysql?

function createSalt()
{
    $string = md5(uniqid(rand(), true));
    return substr($string, 0, 3);
}

$salt = createSalt();

$hash = sha1($salt . $hash);


Zobacz także tę odpowiedź i przeczytaj sekcję o haszowaniu haseł.
Ja͢ck

Odpowiedzi:


110

Ani. Powinieneś użyć bcrypt. Wszystkie wspomniane skróty są zoptymalizowane pod kątem szybkości i łatwości obsługi sprzętu, a więc ich łamanie ma te same cechy. Jeśli nie masz innego wyboru, pamiętaj przynajmniej, aby użyć długiej soli i wielokrotnie ponownie mieszać.

Używanie bcrypt w PHP 5.5+

PHP 5.5 oferuje nowe funkcje do mieszania haseł . Jest to zalecane podejście do przechowywania haseł w nowoczesnych aplikacjach internetowych.

// Creating a hash
$hash = password_hash($password, PASSWORD_DEFAULT, ['cost' => 12]);
// If you omit the ['cost' => 12] part, it will default to 10

// Verifying the password against the stored hash  
if (password_verify($password, $hash)) {
    // Success! Log the user in here.
}

Jeśli używasz starszej wersji PHP , naprawdę powinieneś uaktualnić , ale dopóki tego nie zrobisz, możesz użyć password_compat do udostępnienia tego API.

Pozwól również, aby password_hash()wygenerowano dla Ciebie sól. Używa CSPRNG .

Dwa zastrzeżenia bcrypt

  1. Bcrypt po cichu obcina każde hasło dłuższe niż 72 znaki.
  2. Bcrypt obetnie po jakimkolwiek NULznaku.

( Proof of Concept dla obu zastrzeżeń tutaj.)

Możesz ulec pokusie, aby rozwiązać pierwsze zastrzeżenie przez wstępne zhaszowanie haseł przed uruchomieniem ich przez bcrypt , ale może to spowodować, że aplikacja zacznie działać w drugim.

Zamiast pisać własny schemat, skorzystaj z istniejącej biblioteki napisanej i / lub ocenionej przez ekspertów ds. Bezpieczeństwa.

TL; DR - użyj bcrypt .


1
jestem w tym bardzo nowy: czy sha1, sha256 i md5 to wszystkie „skróty”, o których mówisz?
Tony Stark

3
Tak. Mam na myśli SHA1, SHA256 i MD5 oraz szereg innych skrótów, które są zoptymalizowane pod kątem szybkości. Nie chcesz używać skrótu zoptymalizowanego pod kątem szybkości, aby zabezpieczyć hasło. Jest wiele dobrych artykułów omawiających przyczyny, a szczególnie mi się podoba ten: chargen.matasano.com/chargen/2007/9/7/…
Johannes Gorset,

4
Jest zawarty w funkcji "crypt" od PHP 5.3. Jeśli masz wcześniejszą wersję, zajrzałbym do frameworka „phpass” pod kątem następnej najlepszej rzeczy.
Johannes Gorset

3
@Stanislav Palatnik SHA512 to dobra alternatywa. Nie zrozum mnie źle; Nie mówię, że rozciągnięty i solony hash SHA512 jest niepewny. To jest bezpieczne. Mimo to, pozostaje faktem, że bcrypt jest bardziej bezpieczny, a więc nie widzę powodu, aby nie go używać.
Johannes Gorset

10
@Cypher: bcryptma być powolny, aby był równie powolny do łamania.
Johannes Gorset,

23

Myślę, że używanie md5 lub sha256 lub dowolnego skrótu zoptymalizowanego pod kątem szybkości jest całkowicie w porządku i jestem bardzo ciekawy, jak inni użytkownicy mogą się zemścić. Oto moje powody

  1. Jeśli pozwolisz użytkownikom używać słabych haseł, takich jak Bóg, miłość, wojna, pokój, to bez względu na szyfrowanie nadal będziesz zezwalać użytkownikowi na wpisanie hasła, a nie skrótu, a te hasła są często używane jako pierwsze, więc to NIE będzie mieć cokolwiek wspólnego z szyfrowaniem.

  2. Jeśli nie używasz SSL lub nie masz certyfikatu, atakujący nasłuchujący ruchu będą w stanie wyciągnąć hasło, a wszelkie próby zaszyfrowania za pomocą javascript itp. Będą po stronie klienta i łatwo je złamać i pokonać. Znowu to NIE będzie miało nic wspólnego z szyfrowaniem danych po stronie serwera.

  3. Ataki siłowe wykorzystają słabe hasła i ponownie, ponieważ pozwalasz użytkownikowi wprowadzić dane, jeśli nie masz ograniczenia logowania wynoszącego 3 lub nawet trochę więcej, problem ponownie NIE będzie miał nic wspólnego z szyfrowaniem danych.

  4. Jeśli twoja baza danych zostanie naruszona, najprawdopodobniej wszystko zostało naruszone, w tym twoje techniki haszowania, bez względu na to, jak tajemniczy zostałeś. Znowu może to być atak XSS niezadowolonego pracownika, wstrzyknięcie sql lub inny atak, który nie ma nic wspólnego z szyfrowaniem hasła.

Uważam, że nadal powinieneś szyfrować, ale jedyne, co widzę, że szyfrowanie robi, to uniemożliwia ludziom, którzy już mają lub w jakiś sposób uzyskali dostęp do bazy danych, po prostu głośno odczytując hasło. Jeśli jest to ktoś nieautoryzowany w bazie danych, masz większe problemy, o które musisz się martwić, dlatego Sony zostało zabrane, ponieważ uważali, że zaszyfrowane hasło chroni wszystko, w tym numery kart kredytowych, wszystko, co robi, to chroni to jedno pole, to wszystko.

Jedyną czystą korzyścią, jaką widzę w złożonym szyfrowaniu haseł w bazie danych, jest opóźnienie odczytania haseł przez pracowników lub inne osoby, które mają do niej dostęp. Więc jeśli jest to mały projekt lub coś, czego nie martwiłbym się zbytnio o bezpieczeństwo po stronie serwera, zamiast tego martwiłbym się bardziej o zabezpieczenie wszystkiego, co klient może wysłać do serwera, takiego jak sql injection, ataki XSS lub mnóstwo innych sposobów mogą zostać naruszone. Jeśli ktoś się nie zgadza, z niecierpliwością czekam na przeczytanie, w jaki sposób super zaszyfrowane hasło jest koniecznością po stronie klienta.

Powodem, dla którego chciałem to wyjaśnić, jest to, że zbyt często ludzie uważają, że zaszyfrowane hasło oznacza, że ​​nie muszą się martwić, że zostanie ono naruszone, i przestali martwić się o zabezpieczenie witryny.


1
Dobrze powiedziane. Cyberbezpieczeństwo powinno być preferowane nad technikami haszowania, które nie tylko zapisują twoje dane, ale także zapewniają gotowość obrony serwera.
CᴴᴀZ

14
To jest naprawdę źle poinformowane. Oczywiście bezpieczne haszowanie haseł w bazie danych nie poprawia bezpieczeństwa na poziomie aplikacji lub bazy danych. To nie wszystko dla bezpieczeństwa. Chcesz bezpiecznie zaszyfrować hasło użytkownika w swojej bazie danych z 2 powodów; po pierwsze klient ufa Ci swoim hasłem, którego może użyć lub nie w innych witrynach, więc chcesz mieć pewność, że nie da się go odzyskać, nawet jeśli twoja baza danych jest zagrożona, po drugie, chcesz usunąć odpowiedzialność w przypadku bezpieczeństwa wyłom. Nie znam żadnych pozwów sądowych od ręki, ale wyciekające hasła sprawiają, że Twoja firma wygląda naprawdę źle.
James McMahon,

6
To zła rada. Jeśli ktoś ukradnie twoją bazę danych i otrzyma wszystkie twoje zaszyfrowane hasła, nawet jeśli włamał się również na inne części twojej bazy danych, nadal ważne może być zapobieganie łamaniu haseł i logowaniu się. (Pomyśl na przykład o witrynie bankowej). Algorytmy zoptymalizowane pod kątem szybkości umożliwiają atakującym testowanie wielu kandydatów pod kątem skradzionych skrótów, dopóki nie znajdą dopasowania. Algorytmy takie jak bcrypt i scrypt sprawiają, że testowanie kandydatów pod kątem wartości skrótu jest powolne i kosztowne, nawet jeśli wiedzą, jakiego algorytmu używasz. Dają więc lepszą ochronę, jeśli ktoś ukradnie skróty.
Richard

6
„Jeśli twoja baza danych zostanie naruszona, najprawdopodobniej wszystko zostało naruszone, łącznie z technikami haszowania, bez względu na to, jak tajemniczy zostałeś przez Ciebie”. To dlaczego bcrypt jest tak ważna. W przypadku bcrypt nie ma znaczenia, czy ktoś ma skróty. Z szybkim algorytmem haszującym, takim jak SHA1 / MD5, robi.
ceejayoz

Myślę, że niektórym z was brakuje tego, że nie ma znaczenia, czy hasło jest bezpieczne w 1000%, podczas gdy wszystkie inne dane są zwykłym tekstem. Na przykład, jeśli cała baza danych jest zagrożona, haker ma teraz wszystkie numery kart kredytowych w postaci zwykłego tekstu. Tak, wiele osób używa tego samego hasła na różnych stronach internetowych, ale już powiedziano im, żeby tego nie robili, więc to już nie jest nasz problem. Jeśli sama baza danych zawiera poufne informacje, a ich naruszenie jest problemem, zaszyfruj całą bazę danych tak silnie, jak uważasz za konieczne.
UncaAlby

15

Jak zauważył Johannes Gorset, post Thomasa Ptacka z Matasano Security wyjaśnia, dlaczego proste, ogólne funkcje haszujące, takie jak MD5, SHA1, SHA256 i SHA512, są kiepskimi opcjami do haszowania haseł .

Czemu? Są zbyt szybkie - możesz obliczyć co najmniej 1 000 000 skrótów MD5 na sekundę na rdzeń za pomocą nowoczesnego komputera, więc brutalna siła jest możliwa w przypadku większości haseł używanych przez ludzi. A to znacznie mniej niż oparty na GPU klaster serwerów crackerskich!

Solenie bez rozciągania klucza oznacza tylko, że nie można wstępnie obliczyć tęczowego stołu, musisz go zbudować ad hoc dla tej konkretnej soli. Ale to naprawdę nie utrudni sprawy.

Użytkownik @Will mówi:

Wszyscy mówią o tym, jakby ktoś mógł ich zhakować przez internet. Jak już wspomniano, ograniczanie prób uniemożliwia złamanie hasła przez Internet i nie ma nic wspólnego z hashem.

Nie muszą. Najwyraźniej w przypadku LinkedIn wykorzystali powszechną lukę w zabezpieczeniach SQL injection, aby uzyskać tablicę bazy danych logowania i złamać miliony haseł offline.

Następnie wraca do scenariusza ataku offline:

Bezpieczeństwo naprawdę zaczyna działać, gdy cała baza danych jest zagrożona, a haker może następnie wykonać 100 milionów prób hasła na sekundę w stosunku do skrótu md5. SHA512 jest około 10 000 razy wolniejszy.

Nie, SHA512 nie jest 10000 razy wolniejszy niż MD5 - zajmuje tylko około dwa razy więcej. Z drugiej strony Crypt / SHA512 to zupełnie inna bestia, która, podobnie jak jej odpowiednik w BCrypt, wykonuje rozciąganie klucza , wytwarzając zupełnie inny hash z wbudowaną losową solą i będzie wymagał od 500 do 999999 razy więcej do obliczenia (rozciąganie jest przestrajalne).

SHA512 => aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
Crypt/SHA512 => $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

Zatem wybór dla PHP to Crypt / Blowfish (BCrypt), Crypt / SHA256 lub Crypt / SHA512. Lub przynajmniej Crypt / MD5 (PHK). Zobacz www.php.net/manual/en/function.crypt.php


Proste mieszanie haseł jest w porządku, bezpieczeństwo serwera zależy od zapory ogniowej .. a przez „zaporę ogniową” mam na myśli reaktywną zaporę ogniową, która blokuje / spowalnia brutalną siłę (człowiek może pisać tylko TAK szybko). konkurs nie ma sensu… .. „co by było, gdyby jakiś haker się włamał i teraz ma wszystko” (face-desk) - jeśli haker dostał się do twojego serwera - to koniec. Hasła są łamane głównie dlatego, że są cholernie proste lub programiści są zbyt leniwi, by myśleć jak cyberprzestępca.

@argon Przeczytaj ponownie. Głównym celem haszowania haseł jest to, aby w przypadku naruszenia bezpieczeństwa bazy danych logowania (i w pewnym momencie tak się stanie), nie nastąpi natychmiastowy wyciek wszystkich haseł użytkowników, które są najczęściej ponownie wykorzystywane przez użytkowników w różnych witrynach - w przeciwnym razie prosta opóźnienie po wejściu wystarczy. I „koniec gry, gdy dotarli na serwerze” to punkt sporny, ponieważ nie trzeba się wewnątrz serwera. Najczęstszą luką w zabezpieczeniach hakerów jest wstrzyknięcie SQL (zobacz przypadek Linkedin), a następnie brutalnie forsują hash. Dlatego potrzebujesz solenia i rozciągania.
LexLythius

Jeśli wymagania dotyczące bezpieczeństwa są naprawdę tak wysokie, przechowywanie haseł w innym miejscu może być dobrym pomysłem. Istnieje wiele sposobów ochrony danych (i kodu źródłowego) - w przypadku „jeśli / kiedy”… .. - ale haszowanie haseł do „miliardów bitów” jest tak bezpieczne, jak: twórca haseł / system gościa , transmisji danych i ludzi obsługujących sprzęt serwera. .. to powiedziawszy: NIE mówię, że haszowanie jest bezużyteczne, ale mówię, że jeśli twoje rozwiązanie jest po prostu bardziej skomplikowanym hashem, to obawiam się, że nie zadziała w najbliższej przyszłości, jeśli chodzi o komputery kwantowe.

Cykliczne haszowanie zwiększa nakład pracy / kosztów przy wszelkich próbach włamania. Im więcej iteracji, tym trudniej złamać, więc nawet szybkie skróty, takie jak SHA256, mogą być używane. Iteracje muszą być losowe i mogą być upublicznione. password_hash()pokazuje koszt w samym skrócie.
Victor Stoddard,

@VictorStoddard Tak, możesz utworzyć własny schemat mieszania i zapewnić przestrajalne rozciąganie klucza. Ale dlaczego miałbyś chcieć to zrobić, zamiast korzystać z już istniejących, znacznie dokładniej zbadanych algorytmów, które eksperci stworzyli i udostępnili właśnie w tym celu?
LexLythius

13

Użyj SHA256. Nie jest doskonały, jak SHA512byłby idealny do szybkiego haszowania, ale poza opcjami jest to ostateczny wybór. Jak w przypadku każdej technologii haszowania, pamiętaj, aby posolić hash, aby zwiększyć bezpieczeństwo.

Jako dodatkowa uwaga, FRKT, proszę mi pokazać, gdzie ktoś może łatwo złamać solony haszysz SHA256? Naprawdę bardzo mnie to interesuje.

Ważna edycja:

Przechodząc do przodu, użyj bcryptjako utwardzonego skrótu. Więcej informacji można znaleźć tutaj .


Edytuj na temat solenia:

Użyj losowej liczby lub losowego strumienia bajtów itp. Możesz użyć unikalnego pola rekordu w swojej bazie danych jako soli, w ten sposób sól jest różna dla każdego użytkownika.


1
Ale są zoptymalizowane pod kątem szybkości, co oznacza, że ​​umożliwiają hakowanie z użyciem brutalnej siły.
arbales

6
Fakt pozostaje, ma to na celu zabezpieczenie hasła. Używając hasha z solą, a następnie dodając limit 3 prób na stronie, znacznie spowalniasz próby hakerów (nawet brutalnych forcerów). Korzystając z czystego szyfrowania, masz teraz inny problem - zabezpieczenie klucza. Jeśli klucz zostanie znaleziony, cała baza danych jest zagrożona (jeśli nie dodano soli). Hashe jednak nigdy nie wyjmiesz oryginalnego hasła z systemu i tak powinno być.
Kyle Rosendo

1
Jak zauważono, problem z seriami MD i SHA polega na tym, że są one zoptymalizowane pod kątem szybkości. Jest nieuniknione, że takie skróty stają się coraz bardziej niepewne w miarę ewolucji informatyki.
Johannes Gorset,

1
Wszystko staje się coraz bardziej złe / niepewne / itp. Wraz z rozwojem komputerów. Do czasu zhakowania SHA512 itp. Dostępne będą bezpieczniejsze algorytmy. Taka jest natura przetwarzania w każdym przypadku.
Kyle Rosendo

1
jaki jest dobry sposób na zrobienie soli w php? masz przykładowy kod? Wyobrażam sobie, że nie powinienem po prostu wybierać czegoś takiego jak `` żyrafa ''
Tony Stark

4

Wydaje się, że ludziom brakuje tego, że jeśli haker ma dostęp do bazy danych, prawdopodobnie ma również dostęp do pliku php, który haszuje hasło i prawdopodobnie może po prostu zmodyfikować to, aby wysłać mu wszystkie udane kombinacje haseł nazwy użytkownika. Jeśli nie ma dostępu do katalogu internetowego, zawsze może po prostu wybrać skrót hasła i zapisać go w bazie danych. Innymi słowy, algorytm skrótu nie ma tak dużego znaczenia, jak bezpieczeństwo systemu, a ograniczanie prób logowania również, jeśli nie używasz protokołu SSL, atakujący może po prostu podsłuchać połączenie, aby uzyskać informacje. O ile algorytm nie potrzebuje dużo czasu na obliczenie (do własnych celów), to SHA-256 lub SHA-512 z solą specyficzną dla użytkownika powinno wystarczyć.

Jako dodatkowy środek bezpieczeństwa skonfiguruj skrypt (bash, batch, python itp.) Lub program i nadaj mu niejasną nazwę oraz poproś o sprawdzenie i zobaczenie, czy login.php się zmienił (sprawdź datę / znacznik czasu) i wyślij e-mail jeśli tak. Powinien również prawdopodobnie rejestrować wszystkie próby logowania z uprawnieniami administratora i rejestrować wszystkie nieudane próby zalogowania się do bazy danych i przesyłać dzienniki pocztą elektroniczną.


„Wydaje się, że ludziom brakuje tego, że skoro haker ma dostęp do bazy danych, prawdopodobnie ma również dostęp do pliku php, który zawiera skrót hasła…” To nieprawda. Jedną z najczęstszych luk w zabezpieczeniach jest iniekcja SQL, która dawałaby możliwość odczytu / zapisu bazy danych, ale zerowy dostęp do kodu PHP.
ceejayoz

Jeśli masz dostęp do kodu, możesz zmodyfikować i zapisać całe hasło, które wysyła użytkownik, w postaci zwykłego tekstu. Więc nie, jeśli złamany zostanie kod, to GAME OVER.
magallanes

3

Wszyscy mówią o tym, jakby ktoś mógł ich zhakować przez internet. Jak już wspomniano, ograniczanie prób uniemożliwia złamanie hasła przez Internet i nie ma nic wspólnego z hashem.

Sól jest koniecznością, ale złożoność lub wiele soli nie ma nawet znaczenia. Sama sól powstrzymuje atakującego przed użyciem gotowego tęczowego stołu. Unikalna sól na użytkownika powstrzymuje atakującego przed utworzeniem nowej tęczowej tabeli do wykorzystania przeciwko całej bazie użytkowników.

Bezpieczeństwo naprawdę zaczyna działać, gdy cała baza danych jest zagrożona, a haker może następnie wykonać 100 milionów prób hasła na sekundę w stosunku do skrótu md5. SHA512 jest około 10 000 razy wolniejszy. Złożone hasło o dzisiejszej mocy może nadal wymagać 100 lat, aby zmusić się do działania z md5 i 10 000 razy dłużej z SHA512. Sole w ogóle nie zatrzymują brutalnej siły, ponieważ zawsze muszą być znane, które jeśli atakujący pobrał twoją bazę danych, prawdopodobnie i tak był w twoim systemie.


1

MD5 jest zła z powodu problemów z kolizją - dwa różne hasła mogą generować ten sam MD-5.

Sha-1 byłby do tego bezpieczny. Powodem, dla którego przechowujesz soloną wersję hasła sha-1, jest to, że użytkownik nie przechowuje hasła użytkownika w pliku, którego może używać z serwerami innych osób. W przeciwnym razie, jaka to różnica?

Jeśli haker w jakiś sposób wykradnie całą niezaszyfrowaną bazę danych, jedyną rzeczą, jaką robi zaszyfrowane, zaszyfrowane hasło, jest uniemożliwienie mu podszywania się pod użytkownika w celu późniejszego logowania - haker ma już dane.

Jaki pożytek daje atakującemu posiadanie zaszyfrowanej wartości, jeśli to, co wprowadza użytkownik, to zwykłe hasło?

A nawet gdyby haker dysponujący technologią przyszłości mógł wygenerować milion kluczy sha-1 na sekundę w celu przeprowadzenia ataku brutalnej siły, czy serwer obsługiwałby milion logowań na sekundę, aby haker mógł przetestować swoje klucze? Dzieje się tak, jeśli pozwalasz hakerowi spróbować zalogować się przy użyciu solonego sha-1 zamiast hasła, takiego jak normalne logowanie.

Najlepiej jest ograniczyć błędne próby logowania do pewnej rozsądnej liczby - na przykład 25, a następnie wylogować użytkownika na minutę lub dwie. A jeśli skumulowana liczba prób logowania osiągnie 250 w ciągu 24 godzin, zamknij dostęp do konta i wyślij e-mail do właściciela.


Nawet jeśli używam słabszego szyfrowania, praktycznie żaden system nie jest w stanie wytrzymać brutalnego ataku na więcej niż 1 milion prób na sekundę.
magallanes

1
Trzy nieudane logowania i jesteś zablokowany. Kropka, koniec historii. Nawet super głupie hasła, takie jak „1234”, są bezpieczne, jeśli haker najpierw spróbuje „password”, „pa $$ word” i „passw0rd” (zablokuj!). Sposób, w jaki użytkownik odzyskuje dostęp, staje się teraz Twoim punktem krytycznym w zakresie bezpieczeństwa, a to, co robisz, zależy od wielkości bazy użytkowników. 200 użytkowników? Niech zadzwonią po pomoc.
UncaAlby

Czy ta odpowiedź nie ma sensu dla nikogo innego, czy to tylko ja?
Wildcard


1

Użyj argon2i . Funkcja mieszania haseł argon2 wygrała konkurs haszowania haseł.

Inne rozsądne wybory, jeśli przy użyciu argon2 nie jest dostępna, to scrypt , bcrypt i PBKDF2 . Wikipedia zawiera strony dla tych funkcji:

MD5, SHA1 i SHA256 to skróty wiadomości, a nie funkcje mieszania haseł. Nie nadają się do tego celu.

Przejście z MD5 na SHA1 lub SHA512 nie poprawi tak bardzo bezpieczeństwa konstrukcji. Obliczanie skrótu SHA256 lub SHA512 jest bardzo szybkie. Osoba atakująca ze zwykłym sprzętem może nadal próbować dziesiątki milionów (z jednym procesorem) lub nawet miliardy (z jednym procesorem graficznym) haszów na sekundę. Dobre funkcje haszowania haseł obejmują czynnik roboczy, który spowalnia ataki słownikowe.

Oto sugestia dla programistów PHP: przeczytaj FAQ PHP, a następnie użyj password_hash () .


0

Załóżmy następny punkt: hakerzy kradną naszą bazę danych, w tym użytkowników i hasło (zaszyfrowane). A hakerzy utworzyli fałszywe konto z hasłem, które znają.

MD5 jest słaba, ponieważ jest krótka i popularna, a praktycznie każda generacja skrótu bez hasła jest słaba w ataku słownikowym. Ale..

Powiedzmy więc, że nadal używamy MD5 z SOLĄ. Hakerzy nie znają SALT, ale znają hasło konkretnego użytkownika. Mogą więc przetestować: ????? 12345, gdzie 12345 to znane hasło, a ????? to sól. Hakerzy prędzej czy później mogą odgadnąć SALT.

Jeśli jednak użyliśmy MD5 + SALT i zastosowaliśmy MD5, nie ma sposobu na odzyskanie informacji. Jednak powtarzam, MD5 jest nadal krótka.

Na przykład, powiedzmy, że moje hasło to: 12345. SÓL to BILLCLINTON

md5: 827ccb0eea8a706c4c34a16891f84e7b

md5 z hashem: 56adb0f19ac0fb50194c312d49b15378

mD5 z hashem ponad md5: 28a03c0bc950decdd9ee362907d1798a Próbowałem skorzystać z tych usług online i nie znalazłem żadnego, który byłby w stanie go złamać. I to jedyny MD5! (może być tak, jak dzisiaj będzie można złamać, ponieważ wygenerowałem md5 online)

Jeśli chcesz przesadzić, SHA256 jest więcej niż wystarczający, jeśli zastosujesz go z solą i dwukrotnie.

tldr MD5 (HASH + MD5 (hasło)) = ok, ale krótkie, SHA256 jest więcej niż wystarczające.


Problem z używaniem MD5 z solą polega na tym, że komputery mogą stworzyć brutalny atak na jedno hasło z bardzo dużą prędkością. shylor.com/2015/09/14/php-5-5-secure-password-hashing
Shylor

0

Szyfrowanie md5 jest jednym z najgorszych, ponieważ musisz obrócić kod i jest już odszyfrowany. Poleciłbym SHA256. Programuję trochę dłużej i mam dobre doświadczenia. Poniżej byłoby również szyfrowanie.

password_hash() example using Argon2i

<?php
echo 'Argon2i hash: ' . password_hash('rasmuslerdorf', PASSWORD_ARGON2I);
?>
The above example will output something similar to:

Argon2i hash: $argon2i$v=19$m=1024,t=2,p=2$YzJBSzV4TUhkMzc3d3laeg$zqU/1IN0/AogfP4cmSJI1vc8lpXRW9/S0sYY2i2jHT0
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.