Jak zaimplementować salt do mojego loginu dla haseł?

Celem salt jest uniemożliwienie atakującym amortyzacji kosztów ataku brute force w różnych witrynach (lub jeszcze lepiej, gdy używa się innego salt dla każdego użytkownika: Wszystkich użytkowników witryny) poprzez wstępnie obliczone rainbow tables.

Za pomocą zwykłego hashowania atakujący może obliczyć taką tabelę raz (bardzo długa, kosztowna operacja), a następnie użyć jej do szybkiego znalezienia haseł dla dowolnej witryny. Gdy strona używa jednej stałej soli, atakujący musi obliczyć nową tabelę specjalnie dla tego miejscu. Gdy witryna używa innej soli dla każdego użytkownika, atakujący może przestać zadręczać się rainbow tables - będzie musiał brutalnie wymusić każde hasło osobno.

Przechowywanie soli oddzielnie nie jest konieczne, aby uzyskać tę przewagę. Teoretycznie byłoby to jeszcze bardziej bezpieczne, ponieważ zneutralizowałoby słabość słownika czy krótkich haseł. W praktyce nie warto się tym przejmować, bo na koniec dnia trzeba mieć dostęp do soli gdzieś , aby sprawdzić hasła. Ponadto próba ich oddzielenia doprowadziłaby do powstania bardziej złożonych systemów - a im bardziej skomplikowany jest system, tym większe są możliwości występowania luk w zabezpieczeniach.

Edit: moje konkretne zalecenia:

• Wygeneruj długi pseudorandom soli dla każdego użytkownika i przechowuj w DB
• użyj hasha opartego na bcrypt
• najlepiej, nie wdrażaj go samodzielnie, użyj istniejącej biblioteki zamiast

Zapomnij o używaniu soli (częściowo z powodu, o którym wspominasz), użyj zamiast tego bcrypt:

Aby uzyskać dobre wyjaśnienie Zobacz: http://codahale.com/how-to-safely-store-a-password/

Inne odpowiedzi są dobre, więc dorzucę drobną kwestię, o której nikt inny nie wspomniał. Nie chcesz używać tego samego soli dla każdego hasła, ponieważ jeśli dwie osoby mają to samo hasło, będą miały ten sam hash. To ujawnienie informacji, które napastnik może wykorzystać.

Można by użyć tej samej soli dla każdego użytkownika wraz z dobrym pomysłem Juraja, aby połączyć hasło z innymi nie zmieniającymi się polami bazy danych (unikalnymi dla użytkownika). Ale uważaj, bo to informacje są powiązane z hasłem. Jeśli mielibyście hashować nazwę użytkownika i hasło razem, aby zagwarantować unikalny hash, nie mielibyście możliwości zmiany nazwy użytkownika bez utworzenia nowego użytkownika i wymagania od niego ustawienia nowego hasła.

Jako przykład posiadania unikalnej soli na użytkownika i przechowywania jej obok hasha hasła, wskażę /etc/shadow na typowym systemie Linux.

root@linux:/root# cat /etc/shadow | grep root
root:$1$oL5TTZxL$RhfGUZSbFwQN6jnX5D.Ck/:12139:0:99999:7:::

Tutaj oL5TTZxL jest solą i RhfGUZSbFwQN6jnX5D.Ck / jest hash. W tym przypadku hasło tekstowe to root, a algorytm hashowy, którego używa mój system, to oparty na MD5 algorytm haseł BSD. (nowsze systemy niż moje mają lepsze algorytmy haszujące)

Nie wyciągasz hasła do porównania. Szyfrujesz hasło podczas próby logowania i porównujesz zapisaną wartość z nowo zaszyfrowaną wartością.

Jak wspomniałeś, algorytmy haszujące działają tylko w jedną stronę (lub tylko wtedy, gdy są wystarczająco silne :-D)

Dla Twojego pytania o solowanie polecam hashowanie hasła za pomocą statycznego łańcucha soli i niektórych dynamicznych danych z bazy danych , które powinny nie zmieniać po raz utworzony

Jest to bardzo bezpieczny sposób przechowywania haseł, ponieważ nawet jeśli baza danych jest zagrożona, hakerzy / krakerzy nadal muszą uzyskać statyczny hash string i muszą odgadnąć, jak to zrobić zastosowałem całe solenie..

Na przykład załóżmy, że masz users tabelę z tymi kolumnami:

id
username
password
created_at

Kolumny id i created_at Po wypełnieniu nigdy nie powinny być zmieniane..

Więc kiedy hasasz hasło użytkownika, możesz zrobić tak prosto, jak:

<?php
    $staticSalt = '!241@kadl;ap][';
    $userPass = 'my new pass';
    // assuming $user variable is already populated with DB data
    // we will generate new hash from columns and static salt:
    $genPass = sha1($user['id'] . $userPass . $user['created_at'] . $staticSalt);
?>

Mam nadzieję, że ten pomoże :) pozdrawiam

Hashowanie haseł ma na celu zachowanie tych haseł w tajemnicy przed własnymi administratorami.

1) utrzymywanie haseł tekstowych w bazie danych byłoby w porządku, chyba że hasła mogą być używane przez administratora, aby uzyskać dostęp do innego systemu.

2) możesz użyć pojedynczego globalnego salt, który jest łączony z hasłami (przez prepending lub XORing), a następnie hashuje do przechowywania w bazie danych. Ale to jest podatne na złośliwego administratora i tęczę stół przeznaczony do tej soli.

3) możesz mieć oddzielny salt dla każdego użytkownika: baza danych będzie używana do przechowywania salt, a hash pochodzi z kombinacji hasło / salt. Zapobiegnie to atakowi tęczy, ale ataki brute force nadal będą możliwe.

4) wreszcie, możesz zachować swoją funkcję hash w tajemnicy, używając rozwiązania haszującego sprzętowego o ograniczonej prędkości.

To najlepiej, jak potrafisz. Ze względu na ludzką naturę hasła mają ograniczoną domenę i są podatne na ataki brute force. Staramy się uniemożliwić administratorom przechwytywanie haseł użytkowników, a następnie używanie ich na innych systemach, do których nie powinni mieć dostępu.

Inne uwagi:

A) możesz użyć bcrypt na kombinacji hasło / sól, aby spowolnić atak brute force atakującego. Ale skoro Zakładamy administratorów, mogą być cierpliwi.

B) oddzielenie soli od hasha hasła nie jest skuteczną obroną, jesteśmy zakładając jednak administratorów.

C) wykorzystanie istniejących danych jako soli jest trochę lepsze, ale wątpię, aby istniejące dane miały tyle entropii, ile ma przypadkowa sól.

Zasolenie hasła użytkownika jest prawdopodobnie bezpieczniejsze niż tylko hashowanie hasła, ponieważ może chronić przed atakami prekomputacyjnymi.

Na przykład, jeśli haker uzyska dostęp do twojej bazy danych, a hasła nie zostaną zasolone, może wyszukać hashe w swojej bazie danych (zobacz http://en.wikipedia.org/wiki/Rainbow_table ), Aby uzyskać oryginalne hasła.