Bezpieczny hash i sól dla haseł PHP

Obecnie mówi się, że MD5 jest częściowo niebezpieczny. Biorąc to pod uwagę, chciałbym wiedzieć, którego mechanizmu użyć do ochrony hasłem.

To pytanie: czy „podwójne hashowanie” jest mniej bezpieczne niż jednorazowe hashowanie? sugeruje, że wielokrotne mieszanie może być dobrym pomysłem, podczas gdy jak wdrożyć ochronę hasłem dla poszczególnych plików? sugeruje użycie soli.

Używam PHP. Chcę bezpiecznego i szybkiego systemu szyfrowania hasła. Hashowanie hasła milion razy może być bezpieczniejsze, ale także wolniejsze. Jak osiągnąć równowagę między prędkością a bezpieczeństwem? Ponadto wolałbym, aby wynik miał stałą liczbę znaków.

1. Mechanizm mieszający musi być dostępny w języku PHP
2. To musi być bezpieczne
3. Może używać soli (w tym przypadku, czy wszystkie sole są równie dobre? Czy jest jakiś sposób na wytworzenie dobrych soli?)

Ponadto, czy powinienem przechowywać dwa pola w bazie danych (na przykład jedno przy użyciu MD5, a drugie przy użyciu SHA)? Czy sprawiłoby to, że byłoby bezpieczniej lub mniej?

W przypadku, gdy nie byłem wystarczająco jasny, chcę wiedzieć, które funkcje haszujące mają być używane i jak wybrać dobrą sól, aby mieć bezpieczny i szybki mechanizm ochrony hasłem.

Powiązane pytania, które nie do końca obejmują moje pytanie:

Jaka jest różnica między SHA i MD5 w PHP
Proste szyfrowanie haseł
Bezpieczne metody przechowywania kluczy, haseł do asp.net
Jak zaimplementowałbyś solone hasła w Tomcat 5.5

ZASTRZEŻENIE : Ta odpowiedź została napisana w 2008 roku.

Od tego czasu PHP dał nam, password_hasha password_verifyod ich wprowadzenia są zalecaną metodą mieszania i sprawdzania hasła.

Teoria odpowiedzi jest jednak nadal dobra.

TL; DR

Nie

• Nie ograniczaj znaków, które użytkownicy mogą wprowadzać dla haseł. Robią to tylko idioci.
• Nie ograniczaj długości hasła. Jeśli użytkownicy chcą zdania z superkalifragilisticexpialidocious, nie przeszkadzaj mu w jego użyciu.
• Nie usuwaj ani nie usuwaj znaków HTML i znaków specjalnych w haśle.
• Nigdy nie przechowuj hasła użytkownika w postaci zwykłego tekstu.
• Nigdy nie wysyłaj hasła do użytkownika, chyba że je utracił, a Ty wysłałeś hasło tymczasowe.
• Nigdy, nigdy nie loguj haseł w żaden sposób.
• Nigdy nie mieszaj haseł z SHA1, MD5, a nawet SHA256! Współczesne urządzenia do krakowania mogą przekraczać odpowiednio 60 i 180 miliardów skrótów / sekundę.
• Nie mieszaj bcrypta z surowym wyjściem hash () , albo używaj wyjścia hex lub base64_encode. (Dotyczy to wszelkich danych wejściowych, które mogą zawierać nieuczciwych \0, które mogą poważnie osłabić bezpieczeństwo).

Dos

• Użyj scrypt, kiedy możesz; bcrypt, jeśli nie możesz.
• Użyj PBKDF2, jeśli nie możesz używać ani bcrypt, ani scrypt, z skrótami SHA2.
• Zresetuj hasła wszystkich użytkowników, gdy baza danych zostanie naruszona.
• Zastosuj rozsądną minimalną długość 8–10 znaków, a także wymagaj co najmniej 1 dużej litery, 1 małej litery, cyfry i symbolu. Poprawi to entropię hasła, co z kolei utrudni jego złamanie. (Zobacz sekcję „Co stanowi dobre hasło?” W celu przeprowadzenia debaty).

Po co w ogóle hasła hash?

Cel mieszania haseł jest prosty: zapobieganie złośliwemu dostępowi do kont użytkowników poprzez naruszenie bazy danych. Tak więc celem mieszania haseł jest zniechęcenie hakera lub crackera, który kosztuje go zbyt wiele czasu lub pieniędzy, aby obliczyć hasła w postaci zwykłego tekstu. A czas / koszt to najlepsze środki odstraszające w twoim arsenale.

Innym powodem, dla którego chcesz mieć dobry, solidny hash na kontach użytkowników, jest dać ci wystarczająco dużo czasu na zmianę wszystkich haseł w systemie. Jeśli baza danych zostanie naruszona, będziesz potrzebować wystarczająco dużo czasu na przynajmniej zablokować system, jeśli nie, zmień każde hasło w bazie danych.

Jeremiah Grossman, dyrektor techniczny Whitehat Security, stwierdził na blogu White Hat Security po niedawnym odzyskaniu hasła, które wymagało brutalnego złamania jego ochrony hasłem:

Co ciekawe, żyjąc tym koszmarem, nauczyłem się DUŻO, że nie wiedziałem o łamaniu haseł, przechowywaniu i złożoności. Zrozumiałem, dlaczego przechowywanie haseł jest zawsze o wiele ważniejsze niż złożoność haseł. Jeśli nie wiesz, jak przechowywane jest twoje hasło, to wszystko, na czym naprawdę możesz polegać, to złożoność.To może być powszechna wiedza dla specjalistów od haseł i szyfrowania, ale dla przeciętnego eksperta InfoSec lub Web Security bardzo w to wątpię.

(Podkreśl moje.)

Co właściwie czyni dobre hasło?

Entropia . (Nie to, że w pełni popieram punkt widzenia Randalla.)

Krótko mówiąc, entropia określa, ile zmian zawiera hasło. Gdy hasło składa się tylko z małych liter rzymskich, to tylko 26 znaków. To nie jest duża różnorodność. Hasła alfanumeryczne są lepsze i mają 36 znaków. Jednak uwzględnienie wielkich i małych liter z symbolami to około 96 znaków. To o wiele lepsze niż tylko litery. Jednym z problemów jest to, że aby nasze hasła były niezapomniane, wstawiamy wzory - co zmniejsza entropię. Ups!

Entropia hasła jest przybliżona łatwo . Korzystanie z pełnego zakresu znaków ascii (około 96 znaków pisanych na maszynie) daje entropię 6,6 na znak, co przy 8 znakach dla hasła jest wciąż zbyt niskie (52,679 bitów entropii) dla przyszłego bezpieczeństwa. Ale dobrą wiadomością jest: dłuższe hasła i hasła ze znakami Unicode, naprawdę zwiększają entropię hasła i utrudniają złamanie.

Dłuższa dyskusja na temat entropii hasła na stronie Crypto StackExchange . Dobra wyszukiwarka Google również przyniesie wiele wyników.

W komentarzach rozmawiałem z @popnoodles, który zauważył, że egzekwowanie polityki haseł o długości X z X wieloma literami, cyframi, symbolami itp. Może faktycznie zmniejszyć entropię, czyniąc schemat haseł bardziej przewidywalnym. Zgadzam się. Losowość, tak prawdziwie losowa, jak to tylko możliwe, jest zawsze najbezpieczniejszym, ale najmniej pamiętnym rozwiązaniem.

O ile mogłem powiedzieć, tworzenie najlepszego hasła na świecie to Catch-22. Albo nie jest niezapomniany, zbyt przewidywalny, zbyt krótki, zbyt wiele znaków Unicode (trudne do wpisania na urządzeniu z systemem Windows / Mobile), zbyt długi itp. Żadne hasło nie jest wystarczająco dobre do naszych celów, więc musimy je chronić, tak jakby były w Fort Knox.

Najlepsze praktyki

Bcrypt i scrypt są obecne najlepsze praktyki. Scrypt będzie lepszy od bcrypt w czasie, ale nie widziałem przyjęcia go jako standardu przez Linux / Unix lub przez serwery WWW i nie opublikowano jeszcze szczegółowych recenzji jego algorytmu. Jednak przyszłość algorytmu wygląda obiecująco. Jeśli pracujesz z Ruby, istnieje klejnot scrypt , który ci pomoże, a Node.js ma teraz swój własny pakiet scrypt . Można użyć Scrypt w PHP albo poprzez Scrypt przedłużenia lub Libsodium rozszerzenia (oba są dostępne w PECL).

Gorąco polecam przeczytanie dokumentacji funkcji kryptograficznej, jeśli chcesz zrozumieć, jak korzystać z bcrypt, lub znaleźć dobre opakowanie lub użyć czegoś takiego jak PHPASS, aby uzyskać bardziej starszą implementację. Polecam minimum 12 rund bcrypt, jeśli nie 15 do 18.

Zmieniłem zdanie na temat korzystania z bcrypt, kiedy dowiedziałem się, że bcrypt używa tylko harmonogramu klucza blowfish, z mechanizmem zmiennego kosztu. To drugie pozwala zwiększyć koszt brutalnej siły hasła poprzez zwiększenie i tak drogiego kluczowego harmonogramu blowfish.

Średnie praktyki

Prawie nie wyobrażam sobie już takiej sytuacji. PHPASS obsługuje PHP 3.0.18 do 5.3, więc można go używać w prawie każdej możliwej instalacji - i powinien być używany, jeśli nie wiesz na pewno, że twoje środowisko obsługuje bcrypt.

Załóżmy jednak, że nie można w ogóle używać bcrypt ani PHPASS. Co wtedy?

Wypróbuj implementację PDKBF2 z maksymalną liczbą rund, którą twoje środowisko / aplikacja / postrzeganie użytkownika może tolerować. Najniższa zalecana przeze mnie liczba to 2500 rund. Upewnij się również, że używasz hash_hmac (), jeśli jest on dostępny, aby utrudnić odtwarzanie operacji.

Przyszłe praktyki

W PHP 5.5 znajduje się pełna biblioteka do ochrony hasłem, która odciąga wszelkie problemy związane z pracą z bcrypt. Podczas gdy większość z nas utknęła w PHP 5.2 i 5.3 w większości popularnych środowisk, zwłaszcza hostów współdzielonych, @ircmaxell zbudował warstwę kompatybilności dla nadchodzącego API, która jest wstecznie kompatybilna z PHP 5.3.7.

Podsumowanie kryptografii i wyłączenie odpowiedzialności

Moc obliczeniowa wymagana do złamania zaszyfrowanego hasła nie istnieje. Jedynym sposobem na „złamanie” hasła przez komputer jest jego ponowne utworzenie i symulacja algorytmu mieszającego używanego do jego zabezpieczenia. Szybkość skrótu jest liniowo związana z jego zdolnością do brutalnej siły. Co gorsza, większość algorytmów mieszających można łatwo zrównoleglić, aby działać jeszcze szybciej. Dlatego tak ważne są kosztowne programy, takie jak bcrypt i scrypt.

Nie możesz przewidzieć wszystkich zagrożeń ani dróg ataku, dlatego musisz dołożyć wszelkich starań, aby chronić użytkowników z góry . Jeśli tego nie zrobisz, możesz nawet przegapić fakt, że zostałeś zaatakowany, dopóki nie będzie za późno ... i jesteś odpowiedzialny . Aby uniknąć tej sytuacji, na początku działaj paranoikiem. Atakuj własne oprogramowanie (wewnętrznie) i próbuj kraść poświadczenia użytkownika lub modyfikować konta innych użytkowników lub uzyskiwać dostęp do ich danych. Jeśli nie przetestujesz bezpieczeństwa swojego systemu, nie możesz obwiniać nikogo oprócz siebie.

Wreszcie: nie jestem kryptografem. Cokolwiek powiedziałem, to moja opinia, ale wydaje mi się, że opiera się na dobrym rozsądku ... i dużej ilości lektury. Pamiętaj, bądź tak paranoikiem, jak to tylko możliwe, staraj się jak najtrudniej przeszkadzać, a następnie, jeśli nadal się martwisz, skontaktuj się z białym hakerem lub kryptografem, aby zobaczyć, co mówią o twoim kodzie / systemie.

O wiele krótsza i bezpieczniejsza odpowiedź - w ogóle nie pisz własnego mechanizmu hasła , użyj sprawdzonego mechanizmu.

• PHP 5.5 lub nowszy: password_hash () jest dobrej jakości i stanowi część rdzenia PHP.
• Starsze wersje PHP: biblioteka phpass OpenWall jest znacznie lepsza niż większość niestandardowych kodów - używanych w WordPress, Drupal itp.

Większość programistów po prostu nie ma wystarczającej wiedzy, aby bezpiecznie pisać kod związany z kryptografią bez wprowadzania luk.

Szybki autotest: co to jest rozciąganie hasła i ile iteracji należy użyć? Jeśli nie znasz odpowiedzi, powinieneś użyć password_hash(), ponieważ rozciąganie hasła jest teraz kluczową cechą mechanizmów haseł ze względu na znacznie szybsze procesory oraz użycie procesorów graficznych i układów FPGA do łamania haseł z szybkością miliardów zgadnięć na sekundę (w przypadku układów GPU ).

Na przykład możesz złamać wszystkie 8-znakowe hasła systemu Windows w ciągu 6 godzin przy użyciu 25 procesorów graficznych zainstalowanych na 5 komputerach stacjonarnych. Jest to brutalne wymuszanie, tj. Wyliczanie i sprawdzanie każdego 8-znakowego hasła systemu Windows , w tym znaków specjalnych, i nie jest atakiem słownikowym. Tak było w 2012 r., Od 2018 r. Można było używać mniejszej liczby GPU lub szybciej pękać z 25 GPU.

Istnieje również wiele ataków tabeli tęczy na hasła systemu Windows, które działają na zwykłych procesorach i są bardzo szybkie. Wszystko to dlatego, że system Windows nadal nie używa hasła ani nie rozciąga haseł, nawet w systemie Windows 10 - nie popełniaj tego samego błędu, co Microsoft!

Zobacz też:

• doskonała odpowiedź zawierająca więcej informacji na temat powodów password_hash()lub phpassnajlepszych sposobów.
• dobry artykuł na blogu z zalecanymi „czynnikami roboczymi” (liczba iteracji) dla głównych algorytmów, w tym bcrypt, scrypt i PBKDF2.

Nie przechowałbym hasła zakodowanego na dwa różne sposoby, ponieważ wtedy system jest co najmniej tak słaby, jak najsłabszy z używanych algorytmów haszujących.

Począwszy od PHP 5.5, PHP ma proste, bezpieczne funkcje do mieszania i weryfikacji haseł, password_hash () i password_verify ()

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Gdy password_hash()jest używany, generuje losową sól i włącza ją do generowanego skrótu (wraz z zastosowanym kosztem i stosowanym algorytmem), password_verify()a następnie odczytuje ten skrót i określa zastosowaną metodę soli i szyfrowania oraz weryfikuje go na podstawie podanego hasła w postaci zwykłego tekstu.

Podanie PASSWORD_DEFAULTinstruuje PHP, aby używał domyślnego algorytmu mieszającego zainstalowanej wersji PHP. Dokładnie, który to algorytm ma zmieniać się w czasie w przyszłych wersjach, aby zawsze był jednym z najsilniejszych dostępnych algorytmów.

Zwiększenie kosztu (domyślnie 10) powoduje, że skrót jest trudniejszy do użycia z użyciem siły, ale oznacza również generowanie skrótów i weryfikowanie haseł względem nich, co będzie więcej pracy dla procesora serwera.

Zauważ, że nawet jeśli domyślny algorytm mieszania może się zmienić, stare skróty będą nadal sprawdzały się dobrze, ponieważ użyty algorytm jest przechowywany w haszu i password_verify()pobiera go.

Chociaż odpowiedź na to pytanie, chcę tylko powtórzyć, że sole używane do mieszania powinny być losowe, a nie jak adres e-mail, jak sugerowano w pierwszej odpowiedzi.

Więcej wyjaśnień można znaleźć na stronie http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Niedawno dyskutowałem, czy skróty haseł solone losowymi bitami są bezpieczniejsze niż te z solami domyslnymi lub znanymi. Zobaczmy: jeśli system przechowujący hasło zostanie naruszony, podobnie jak system przechowujący losową sól, atakujący będzie miał dostęp zarówno do haszu, jak i soli, więc nie ma znaczenia, czy sól jest losowa, czy nie. Atakujący może wygenerować wstępnie obliczone tabele tęczy, aby złamać skrót. Oto interesująca część - generowanie wstępnie obliczonych tabel nie jest tak proste. Weźmy przykład modelu bezpieczeństwa WPA. Twoje hasło WPA nigdy nie jest wysyłane do bezprzewodowego punktu dostępowego. Zamiast tego jest mieszany z Twoim identyfikatorem SSID (nazwa sieci podobna do Linksys, Dlink itp.). Oto bardzo dobre wyjaśnienie tego, jak to działa. Aby odzyskać hasło z skrótu, musisz znać hasło, a także sól (nazwa sieci). Church of Wifi ma już wstępnie obliczone tabele skrótów, które mają najlepsze 1000 identyfikatorów SSID i około 1 miliona haseł. Rozmiar wszystkich tabel wynosi około 40 GB. Jak można przeczytać na ich stronie, ktoś użył 15 tablic FGPA przez 3 dni, aby wygenerować te tabele. Zakładając, że ofiara używa identyfikatora SSID jako „a387csf3” i hasła jako „123456”, czy będzie on łamany przez te tabele? Nie! .. nie może. Nawet jeśli hasło jest słabe, tabele nie mają skrótów dla SSID a387csf3. To jest piękno losowej soli. Odstraszy włamywaczy, którzy rozwijają się przy wcześniej obliczonych stołach. Czy to może powstrzymać zdecydowanego hakera? Prawdopodobnie nie. Ale stosowanie losowych soli zapewnia dodatkową warstwę obrony. Podczas gdy zajmujemy się tym tematem, omówmy dodatkową zaletę przechowywania losowych soli w osobnym systemie. Scenariusz # 1: Hasła hasła są przechowywane w systemie X, a wartości soli używane do mieszania są przechowywane w systemie Y. Te wartości soli są zgadywalne lub znane (np. Nazwa użytkownika) Scenariusz # 2: Hasła hasła są przechowywane w systemie X, a wartości soli są używane dla mieszanie jest przechowywane w systemie Y. Te wartości soli są losowe. W przypadku naruszenia systemu X, jak można się domyślić, ogromną zaletą jest użycie losowej soli w osobnym systemie (scenariusz nr 2). Atakujący będzie musiał odgadnąć wartości dodatkowe, aby móc złamać skróty. Jeśli zostanie użyta 32-bitowa sól, 2 ^ 32 = 4 294 967 296 (około 4,2 miliarda) iteracji będzie wymagane dla każdego odgadniętego hasła. Hasła haseł są przechowywane w systemie X, a wartości soli używane do haszowania są przechowywane w systemie Y. Te wartości soli są zgadywalne lub znane (np. Nazwa użytkownika) Scenariusz # 2: Hasła haseł są przechowywane w systemie X, a wartości soli używane do haszowania są przechowywane w system Y. Te wartości soli są losowe. W przypadku naruszenia systemu X, jak można się domyślić, ogromną zaletą jest użycie losowej soli w osobnym systemie (scenariusz nr 2). Atakujący będzie musiał odgadnąć wartości dodatkowe, aby móc złamać skróty. Jeśli zostanie użyta 32-bitowa sól, 2 ^ 32 = 4 294 967 296 (około 4,2 miliarda) iteracji będzie wymagane dla każdego odgadniętego hasła. Hasła haseł są przechowywane w systemie X, a wartości soli używane do haszowania są przechowywane w systemie Y. Te wartości soli są zgadywalne lub znane (np. Nazwa użytkownika) Scenariusz # 2: Hasła haseł są przechowywane w systemie X, a wartości soli używane do haszowania są przechowywane w system Y. Te wartości soli są losowe. W przypadku naruszenia systemu X, jak można się domyślić, ogromną zaletą jest użycie losowej soli w osobnym systemie (scenariusz nr 2). Atakujący będzie musiał odgadnąć wartości dodatkowe, aby móc złamać skróty. Jeśli zostanie użyta 32-bitowa sól, 2 ^ 32 = 4 294 967 296 (około 4,2 miliarda) iteracji będzie wymagane dla każdego odgadniętego hasła. Te wartości soli są losowe. W przypadku naruszenia systemu X, jak można się domyślić, ogromną zaletą jest użycie losowej soli w osobnym systemie (scenariusz nr 2). Atakujący będzie musiał odgadnąć wartości dodatkowe, aby móc złamać skróty. Jeśli zostanie użyta 32-bitowa sól, 2 ^ 32 = 4 294 967 296 (około 4,2 miliarda) iteracji będzie wymagane dla każdego odgadniętego hasła. Te wartości soli są losowe. W przypadku naruszenia systemu X, jak można się domyślić, ogromną zaletą jest użycie losowej soli w osobnym systemie (scenariusz nr 2). Atakujący będzie musiał odgadnąć wartości dodatkowe, aby móc złamać skróty. Jeśli zostanie użyta 32-bitowa sól, 2 ^ 32 = 4 294 967 296 (około 4,2 miliarda) iteracji będzie wymagane dla każdego odgadniętego hasła.

Chciałbym tylko zauważyć, że PHP 5.5 zawiera API mieszające hasła, które zapewnia otokicrypt() . Ten interfejs API znacznie upraszcza zadanie mieszania, weryfikacji i ponownego hashowania hasła. Autor wydał również pakiet kompatybilności (w postaci jednego pliku password.php, którego po prostu requireużywasz), dla tych, którzy używają PHP 5.3.7 i nowszych i chcą tego teraz używać.

Na razie obsługuje tylko BCRYPT, ale jego celem jest łatwe rozszerzenie go o inne techniki mieszania haseł, a ponieważ technika i koszt są przechowywane jako część skrótu, zmiany preferowanej techniki / kosztu haszowania nie unieważnią bieżących skrótów, frameworka automatycznie zastosuje prawidłową technikę / koszt podczas walidacji. Obsługuje również generowanie „bezpiecznej” soli, jeśli nie zdefiniujesz jej własnej.

Interfejs API udostępnia cztery funkcje:

• password_get_info() - zwraca informacje o danym haszu
• password_hash() - tworzy skrót hasłowy
• password_needs_rehash()- sprawdza, czy dany skrót odpowiada danym opcjom. Przydaje się, aby sprawdzić, czy skrót jest zgodny z aktualną techniką / schematem kosztów, umożliwiając w razie potrzeby powtórzenie skrótu
• password_verify() - sprawdza, czy hasło pasuje do skrótu

W chwili obecnej funkcje te akceptują stałe hasła PASSWORD_BCRYPT i PASSWORD_DEFAULT, które są obecnie synonimami, z tą różnicą, że PASSWORD_DEFAULT „może się zmieniać w nowszych wersjach PHP, gdy obsługiwane są nowsze, silniejsze algorytmy mieszające”. Używanie PASSWORD_DEFAULT i password_needs_rehash () przy logowaniu (i ponownym logowaniu, jeśli to konieczne) powinno zapewnić, że twoje skróty są odpowiednio odporne na ataki typu brute force, przy niewielkim lub żadnym wysiłku.

EDYCJA: Właśnie zdałem sobie sprawę, że jest to krótko wspomniane w odpowiedzi Roberta K. Pozostawię tę odpowiedź tutaj, ponieważ uważam, że zawiera ona nieco więcej informacji o tym, jak działa i łatwość użycia, która zapewnia tym, którzy nie znają bezpieczeństwa.

Używam Phpass, który jest prostą klasą PHP z jednym plikiem, którą można bardzo łatwo zaimplementować w prawie każdym projekcie PHP. Zobacz także H .

Domyślnie używał najsilniejszego dostępnego szyfrowania, które jest zaimplementowane w Phpass, czyli bcrypt i wraca do innych szyfrowań aż do MD5, aby zapewnić wsteczną kompatybilność frameworków takich jak Wordpress.

Zwrócony skrót może być przechowywany w bazie danych bez zmian. Przykładowe użycie do generowania skrótu to:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Aby zweryfikować hasło, możesz użyć:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

RZECZY DO ZAPAMIĘTANIA

Wiele powiedziano o szyfrowaniu haseł dla PHP, z których większość jest bardzo dobrą radą, ale zanim jeszcze zaczniesz używać PHP do szyfrowania haseł, upewnij się, że masz zaimplementowane lub gotowe do wdrożenia.

SERWER

PORTY

Bez względu na to, jak dobre jest Twoje szyfrowanie, jeśli nie odpowiednio zabezpieczysz serwer z PHP i DB, wszystkie twoje wysiłki są bezwartościowe. Większość serwerów działa względnie w ten sam sposób, mają przypisane porty, aby umożliwić ci zdalny dostęp za pośrednictwem ftp lub powłoki. Upewnij się, że zmieniłeś domyślny port, w którym zawsze było aktywne połączenie zdalne. Nie robiąc tego, w efekcie sprawiłeś, że atakujący zrobił jeden krok w dostępie do twojego systemu.

NAZWA UŻYTKOWNIKA

Do wszystkiego, co jest dobre na świecie, nie używaj nazwy użytkownika admin, root lub czegoś podobnego. Również jeśli korzystasz z systemu uniksowego, NIE udostępniaj logowania do konta root, zawsze powinno to być tylko sudo.

HASŁO

Mówisz swoim użytkownikom, aby tworzyli dobre hasła, aby uniknąć włamania, zrób to samo. Jaki jest sens przechodzenia przez cały proces zamykania drzwi wejściowych, gdy tylne drzwi są szeroko otwarte.

BAZA DANYCH

SERWER

Idealnie potrzebujesz DB i APLIKACJI na osobnych serwerach. Nie zawsze jest to możliwe ze względu na koszty, ale zapewnia pewne bezpieczeństwo, ponieważ osoba atakująca będzie musiała przejść dwa kroki, aby uzyskać pełny dostęp do systemu.

UŻYTKOWNIK

Zawsze upewnij się, że Twoja aplikacja ma własne konto, aby uzyskać dostęp do bazy danych i dać mu tylko potrzebne uprawnienia.

Następnie miej dla siebie osobne konto użytkownika, które nie jest przechowywane w dowolnym miejscu na serwerze, nawet w aplikacji.

Jak zawsze NIE twórz tego roota ani czegoś podobnego.

HASŁO

Postępuj zgodnie z tymi samymi wskazówkami, co w przypadku wszystkich dobrych haseł. Nie używaj również tego samego hasła na żadnym koncie SERVER lub DB w tym samym systemie.

PHP

HASŁO

NIGDY NIGDY nie przechowuj hasła w swoim DB, zamiast tego przechowuj skrót i unikalną sól, wyjaśnię dlaczego później.

HASHING

HASŁO JEDEN SPOSÓB !!!!!!!, Nigdy nie haszuj hasła w sposób, który może być odwrócony, Hashe powinny być jednokierunkowe, co oznacza, że ​​nie odwracasz ich i nie porównujesz z hasłem, zamiast tego haszujesz wprowadzone hasło w ten sam sposób i porównaj dwa skróty. Oznacza to, że nawet jeśli atakujący uzyska dostęp do bazy danych, nie wie, jakie jest faktycznie hasło, tylko wynikowy skrót. Co oznacza większe bezpieczeństwo dla użytkowników w najgorszym możliwym scenariuszu.

Istnieje wiele dobrych funkcji haszujących ( password_hash, hashitp.), Ale musisz wybrać dobry algorytm, aby hasz był skuteczny. (bcrypt i podobne do niego to przyzwoite algorytmy).

Kiedy kluczowa jest szybkość mieszania, im wolniejsza, tym bardziej odporna na ataki Brute Force.

Jednym z najczęstszych błędów w mieszaniu jest to, że skróty nie są unikalne dla użytkowników. Wynika to głównie z tego, że sole nie są wytwarzane jednoznacznie.

SÓL

Hasła powinny być zawsze solone przed mieszaniem. Solenie dodaje losowy ciąg do hasła, więc podobne hasła nie pojawiają się w DB. Jeśli jednak sól nie jest unikalna dla każdego użytkownika (tj. Używasz soli zakodowanej na sztywno), to właściwie uczyniłeś ją bezwartościową. Ponieważ gdy atakujący odkryje jedną sól hasła, ma sól dla wszystkich.

Kiedy tworzysz sól, upewnij się, że jest ona unikalna dla hasła, które jest solone, a następnie przechowuj zarówno ukończony hash, jak i sól w DB. W ten sposób sprawi, że atakujący będzie musiał indywidualnie rozbić każdą sól i hasz, zanim będzie mógł uzyskać dostęp. Oznacza to o wiele więcej pracy i czasu dla atakującego.

UŻYTKOWNICY TWORZĄCY HASŁA

Jeśli użytkownik tworzy hasło za pomocą interfejsu, oznacza to, że należy je wysłać na serwer. To otwiera problem bezpieczeństwa, ponieważ oznacza to, że niezaszyfrowane hasło jest wysyłane na serwer, a jeśli osoba atakująca jest w stanie nasłuchiwać i uzyskiwać dostęp, wszystkie zabezpieczenia w PHP są bezwartościowe. ZAWSZE przesyłaj dane BEZPIECZNIE, odbywa się to przez SSL, ale bądź zmęczony, nawet SSL nie jest bezbłędny (wada OpenSSL Heartbleed jest tego przykładem).

Spraw, aby użytkownik utworzył bezpieczne hasło, jest to proste i zawsze powinno być zrobione, użytkownik będzie mu w końcu wdzięczny.

Wreszcie, bez względu na to, że środki bezpieczeństwa, które nie podejmujesz, są w 100% bezpieczne, im bardziej zaawansowana jest technologia ochrony, tym bardziej zaawansowane stają się ataki. Ale wykonanie tych kroków sprawi, że Twoja witryna będzie bezpieczniejsza i mniej pożądana dla atakujących.

Oto klasa PHP, która z łatwością tworzy skrót i sól do hasła

http://git.io/mSJqpw

Google twierdzi, że SHA256 jest dostępny dla PHP.

Zdecydowanie powinieneś użyć soli. Polecam używanie losowych bajtów (i nie ograniczaj się do znaków i cyfr). Jak zwykle, im dłużej wybierzesz, tym bezpieczniej, tym wolniej. Chyba powinno być 64 bajtów.

Ostatecznie, matematycznie podwójne haszowanie nie przynosi żadnych korzyści. W praktyce jest jednak przydatny w zapobieganiu atakom opartym na tabeli tęczy. Innymi słowy, nie przynosi więcej korzyści niż mieszanie soli, co zajmuje znacznie mniej czasu procesora w aplikacji lub na serwerze.

Znalazłem idealny temat na ten temat tutaj: https://crackstation.net/hashing-security.htm , chciałem, abyś mógł z niego skorzystać, oto kod źródłowy, który zapewnił również zapobieganie atakowi opartemu na czasie.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Zwykle używam SHA1 i soli z identyfikatorem użytkownika (lub inną informacją specyficzną dla użytkownika), a czasami dodatkowo używam stałej soli (więc mam 2 części soli).

SHA1 jest teraz również uważany za nieco zagrożony, ale w znacznie mniejszym stopniu niż MD5. Używając soli (dowolnej soli), zapobiegasz użyciu ogólnej tabeli tęczy do atakowania twoich skrótów (niektórym ludziom nawet udało się używać Google jako pewnego rodzaju tabeli tęczy, szukając skrótu). Osoba atakująca może wygenerować tęczową tabelę przy użyciu twojej soli, dlatego powinieneś dołączyć sól specyficzną dla użytkownika. W ten sposób będą musieli wygenerować tęczową tabelę dla każdego rekordu w systemie, a nie tylko dla całego systemu! Przy tego rodzaju soleniu nawet MD5 jest przyzwoicie bezpieczny.

SHA1 i sól powinny wystarczyć (w zależności od tego, czy kodujesz coś dla Fort Knox, czy system logowania do listy zakupów) w dającej się przewidzieć przyszłości. Jeśli SHA1 nie jest dla ciebie wystarczająco dobry, użyj SHA256 .

Ideą soli jest, żeby tak rzec, wytrącenie wyników mieszania z równowagi. Wiadomo na przykład, że skrót MD5 pustego łańcucha to d41d8cd98f00b204e9800998ecf8427e. Więc jeśli ktoś z wystarczająco dobrą pamięcią zobaczy ten skrót i będzie wiedział, że jest to skrót pustego łańcucha. Ale jeśli łańcuch zostanie solony (powiedzmy z łańcuchem „ MY_PERSONAL_SALT”), skrót dla „pustego łańcucha” (tj. „ MY_PERSONAL_SALT”) Stanie się aeac2612626724592271634fb14d3ea6, dlatego nie jest oczywiste, aby śledzić wstecz. To, co próbuję powiedzieć, że lepiej jest użyć jakiejkolwiek soli, niż nie. Dlatego nie jest zbyt ważne, aby wiedzieć, której soli użyć.

Istnieją strony internetowe, które właśnie to robią - możesz podać jej skrót (md5) i wyrzuca znany tekst jawny, który generuje ten konkretny skrót. Jeśli uzyskasz dostęp do bazy danych, która przechowuje zwykłe skróty md5, byłoby trywialne, aby wprowadzić hash dla administratora takiej usługi i zalogować się. Ale jeśli hasła zostałyby solone, taka usługa stałaby się nieskuteczny.

Również podwójne mieszanie jest ogólnie uważane za złą metodę, ponieważ zmniejsza przestrzeń wynikową. Wszystkie popularne skróty mają stałą długość. Zatem możesz mieć tylko skończone wartości o tej stałej długości, a wyniki stają się mniej zróżnicowane. To mogłoby być uznane za inną formę solenia, ale nie polecam go.

ok w fitsy potrzebujemy soli sól musi być unikalna, więc pozwólmy ją wygenerować

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

potrzebujemy też skrótu. Używam sha512, jest najlepszy i jest w php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

więc teraz możemy użyć tych funkcji do wygenerowania bezpiecznego hasła

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

teraz musimy zapisać w bazie danych naszą zmienną $ hash_psw i zmienną $ salt

i do autoryzacji użyjemy tych samych kroków ...

to najlepszy sposób na zabezpieczenie haseł naszych klientów ...

Ps dla ostatnich 2 kroków możesz użyć własnego algorytmu ... ale upewnij się, że możesz wygenerować to zaszyfrowane hasło w przyszłości, kiedy będziesz musiał autoryzować użytkownika ...