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);
Odpowiedzi:
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ć.
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 .
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.
Zend\Crypt (część Zend Framework) BcryptShaPasswordLockjest podobny do, BcryptShaale także szyfruje skróty bcrypt za pomocą uwierzytelnionej biblioteki szyfrowania .TL; DR - użyj bcrypt .
bcryptma być powolny, aby był równie powolny do łamania.
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
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.
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.
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.
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.
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
password_hash()pokazuje koszt w samym skrócie.
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.
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.
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ą.
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.
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.
Oto porównanie między MD5 i SHA1. Możesz uzyskać jasny obraz tego, który jest lepszy.
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 () .
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.
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