Jak sól hasła pomaga w walce z atakiem rainbow table?

Inne odpowiedzi nie wydają się odpowiadać na twoje nieporozumienia w temacie, więc proszę bardzo:

Widziałem wiele samouczków sugerujących, że sól może być używana jako:

$hash = md5($salt.$password)

[...]

Inne zastosowanie, jakie widziałem, jest na moim systemie linux. W /etc/shadow hashowane hasła są faktycznie przechowywane razem z salt.

Ty zawsze musisz przechowywać sól z hasłem, ponieważ w celu sprawdzenia tego, co użytkownik wprowadził w bazie haseł, musisz połączyć dane wejściowe z salt, hashować je i porównać z przechowywanym Hashem.

Zabezpieczenie hasha

Teraz ktoś z tęczową tabelą mógłby odwrócić hash i wymyślić wejście "foobar".

[...]

Od odwrotnego skrótu te5SBM.7C25fFDu6bIRbX jest znany jako "foo".

Nie jest możliwe odwrócenie hasha jako takiego (w teorii, przynajmniej). Hash" foo "i hash" saltfoo " nie mają ze sobą nic wspólnego. Zmiana nawet jednego bitu na wejściu kryptograficznej funkcji skrótu powinna całkowicie zmienić wyjście.

Oznacza to, że nie można zbudować tęczowej tabeli ze wspólnymi hasłami, a następnie "zaktualizować" ją trochę soli. Musisz wziąć sól pod uwagę od początku.

Jakość soli

Ale powiedz $salt=foo

"foo" byłoby wyjątkowo złym wyborem soli. Zwykle używasz losowej wartości zakodowanej w ASCII.

Ponadto każde hasło ma własną sól, inną (miejmy nadzieję) od wszystkich innych soli w systemie. Oznacza to, że atakujący musi zaatakować każde hasło z osobna zamiast mieć nadzieję, że jeden Z hashów pasuje do jednej z wartości w jej bazie danych.

Atak

Jeśli haker w jakiś sposób był w stanie zdobyć ten plik, Nie wiem, Do czego służy sól,

Atak rainbow table zawsze wymaga /etc/passwd (lub jakiejkolwiek bazy haseł), albo jak porównać hashe w rainbow table z hashami rzeczywistego hasła?

Jeśli chodzi o cel: powiedzmy, że atakujący chce zbudować tęczową tabelę dla 100 000 powszechnie używanych angielskich słów i typowych haseł (pomyśl "sekret"). Bez soli musiałaby przeliczać 100,000 haszy. Nawet z tradycyjną uniksową solą złożoną z 2 znaków (każdy z 64 opcji: [a–zA–Z0–9./]) musiałaby obliczyć i zapisać 4 096 000 000 hashów... niezła poprawa.

Pomysł z solą polega na tym, aby trudniej było odgadnąć za pomocą brutalnej siły niż zwykłe hasło oparte na znakach. Tabele tęczowe są często budowane ze specjalnym zestawem znaków i nie zawsze zawierają wszystkie możliwe kombinacje (choć mogą).

Więc dobra wartość salt byłaby losową 128-bitową lub dłuższą liczbą całkowitą. To sprawia, że ataki rainbow-table zawodzą. Używając innej wartości salt dla każdego przechowywanego hasła, możesz również upewnić się, że tablica tęczowa została zbudowana dla jednej konkretnej wartości salt (co może mieć miejsce, jeśli jesteś popularnym systemem z jedną wartością salt) nie daje dostępu do wszystkich haseł jednocześnie.

Jeszcze jedno świetne pytanie, z wieloma bardzo przemyślanymi odpowiedziami - +1 na tak!

Jeden mały punkt, który nie widziałem wymienione wyraźnie jest to, że dodając losową sól do każdego hasła, jesteś praktycznie gwarancją, że dwóch użytkowników , którzy przypadkiem wybrać to samo hasło będzie produkować różne skróty.

Wyobraź sobie bazę haseł w dużej firmie programistycznej w północno-zachodnich Stanach Zjednoczonych. Załóżmy, że zawiera 30 000 wpisów, z czego 500 mA hasło bluescreen . Załóżmy ponadto, że hakerowi udaje się uzyskać to hasło, powiedzmy, czytając je w wiadomości e-mail od użytkownika do działu IT. Jeśli hasła są niesalowane, haker może znaleźć wartość zaszyfrowaną w bazie danych, a następnie po prostu dopasować ją do wzorca, aby uzyskać dostęp do innych kont 499.

Zasolenie haseł gwarantuje, że każde z 500 kont ma unikalne (salt+hasło), generując dla każdego z nich inny hash, a tym samym ograniczenie naruszenia do jednego konta. I miejmy nadzieję, wbrew wszelkiemu prawdopodobieństwu, że każdy użytkownik na tyle naiwny, aby napisać hasło tekstowe w wiadomości e-mail, nie ma dostępu do nieudokumentowanego API dla następnego systemu operacyjnego.

Szukałem dobrej metody zastosowania soli i znalazłem ten doskonały artykuł z przykładowym kodem:

Http://crackstation.net/hashing-security.htm

Autor zaleca używanie losowych soli dla każdego użytkownika, dzięki czemu uzyskanie dostępu do soli nie sprawi, że cała lista skrótów będzie łatwa do złamania.

Aby zapisać hasło:

• Wygeneruj długą losową sól używając CSPRNG.
• dodaj sól do hasła i hashuj je za pomocą standard kryptograficzna funkcja skrótu, taka jak SHA256.
• Zapisz zarówno salt, jak i hash w rekordzie bazy danych użytkownika.

Aby zweryfikować Hasło:

• pobiera sól i hash użytkownika z bazy danych.
• przeprowadź salt do podanego hasła i hashuj je za pomocą tej samej funkcji hash.
• Porównaj hash podanego hasła z Hashem z bazy danych. Jeśli oni dopasowanie, hasło jest poprawne. W przeciwnym razie hasło jest nieprawidłowe.

Powodem, dla którego sól może spowodować niepowodzenie ataku rainbow-table, jest to, że dla N-bitów soli, stół tęczy musi być 2^N razy większy niż rozmiar stołu bez soli.

Twój przykład użycia " foo " jako soli może uczynić Tęczowy stół 16 milionów razy większym.

Biorąc pod uwagę przykład 128-bitowej soli, to sprawia, że stół 2^128 razy większy - teraz jest duży - lub mówiąc inaczej, jak długo zanim ktoś będzie miał tak dużą pamięć przenośną?

Większość metod łamania szyfrowania hashowego opiera się na atakach brute force. Rainbow attack jest zasadniczo bardziej efektywnym atakiem słownikowym, ma na celu wykorzystanie niskich kosztów przechowywania cyfrowego, aby umożliwić tworzenie mapy znaczącego podzbioru możliwych haseł do hashów i ułatwić mapowanie odwrotne. Ten rodzaj ataku działa, ponieważ wiele haseł jest zazwyczaj dość krótkich lub używa jednego z kilku wzorców formatów opartych na słowie.

Takie ataki są nieskuteczne w przypadku, gdy hasła zawierają o wiele więcej znaków i nie są zgodne z powszechnie stosowanymi formatami word. Użytkownik z silnym hasłem na początek nie będzie podatny na ten styl ataku. Niestety wiele osób nie wybiera dobrych haseł. Ale jest kompromis, możesz poprawić hasło użytkownika, dodając do niego losowe śmieci. Więc teraz zamiast" hunter2 "ich hasło może stać się skutecznie" hunter2908!fld2R75{R7/; 508PEzoz^U430", czyli o wiele silniejsze hasło. Jednakże, ponieważ teraz musisz przechowywać ten dodatkowy składnik hasła, zmniejsza to skuteczność silniejszego hasła złożonego. Jak się okazuje, taki schemat jest nadal korzystny, ponieważ teraz każde hasło, nawet te słabe, nie jest już podatne na ten sam wstępnie obliczony hash / tęczową tabelę. Zamiast tego każdy wpis hashowy hasła jest podatny tylko na unikalną tabelę hashową.

Powiedz, że masz stronę, która ma słabe wymagania dotyczące siły hasła. Jeśli nie używasz hasła sól w wszystkie Twoje skróty są podatne na wstępnie obliczone tabele skrótów, ktoś z dostępem do Twoich skrótów miałby więc dostęp do haseł dla dużego odsetka użytkowników(jednak wiele z nich używało haseł podatnych na ataki, co byłoby znacznym odsetkiem). Jeśli używasz stałej soli hasła, wstępnie obliczone tabele hash nie są już cenne, więc ktoś musiałby poświęcić czas, aby obliczyć niestandardową tabelę hash dla tej soli, mógłby to zrobić stopniowo, jednak, obliczając tabele, które obejmują coraz większe permutacje przestrzeni problemowej. Najbardziej narażone hasła (np. proste hasła oparte na słowach, bardzo krótkie hasła alfanumeryczne) byłyby łamane w godzinach lub dniach, mniej podatne hasła byłyby łamane po kilku tygodniach lub miesiącach. W miarę upływu czasu atakujący uzyska dostęp do haseł dla stale rosnącego odsetka użytkowników. Jeśli używasz unikalnego soli dla każdego hasła, uzyskanie dostępu do każdego z tych podatnych na ataki zajęłoby dni lub miesiące hasła.

Jak widać, kiedy stąpasz z braku soli do stałej soli do unikalnej soli, nakładasz kilka rzędów wielkości wzrostu w celu złamania wrażliwych haseł na każdym kroku. Bez soli najsłabsze hasła użytkowników są trywialnie dostępne, ze stałą solą te słabe hasła są dostępne dla zdeterminowanego atakującego, z unikalną solą koszt dostępu do haseł jest tak wysoki, że tylko najbardziej zdeterminowany atakujący może uzyskać dostęp do malutki podzbiór wrażliwych haseł, a potem tylko wielkim kosztem.

W której dokładnie się znajdujemy. Nigdy nie można w pełni chronić użytkowników przed słabym wyborem haseł, ale można podnieść koszty narażania haseł użytkowników do poziomu, który sprawia, że narażanie nawet jednego użytkownika hasło jest zbyt drogie.

Jednym z celów solenia jest pokonanie wstępnie obliczonych tabel hash. Jeśli ktoś ma listę milionów wstępnie obliczonych hashów, nie będzie w stanie znaleźć $1$foo$te5SBM.7C25fFDu6bIRbX1 Nadal będą musieli użyć siły.

Innym celem, jak wspomina Carl S, jest uczynienie brute ' a bardziej kosztownym, zmuszając listę hashów.

Oba te cele są nadal realizowane nawet jeśli sole są publiczne.

Z tego co wiem, sól ma utrudniać ataki słownikowe.

Jest wiadomym faktem, że wiele osób będzie używać zwykłych słów do haseł zamiast pozornie przypadkowych ciągów.

Więc haker mógłby wykorzystać to na swoją korzyść, zamiast używać tylko brutalnej siły. Nie będzie szukał haseł typu aaa, AAB, aac... ale zamiast tego używaj słów i popularnych haseł (takich jak nazwy Władcy Pierścieni! ;) )

Więc jeśli moje hasło to Legolas, haker mógłby spróbować i zgadnąć to z" kilku " próbuje. Jeśli jednak hasło zostanie zasolone i stanie się fooLegolas, hash będzie inny, więc atak słownikowy zakończy się niepowodzeniem.

Mam nadzieję, że to pomoże!

Zakładam, że używasz funkcji PHP - - - md5 () i zmiennych $ - - - wtedy możesz spróbować poszukać tego artykułu Shadow Password HOWTO specjalnie w 11 paragrafie.

Ponadto, boisz się używać algorytmów digest wiadomości, możesz wypróbować prawdziwe algorytmy szyfrowania, takie jak te dostarczane przez moduł mcrypt, lub bardziej silniejsze algorytmy digest wiadomości, takie jak te, które dostarczają moduł mhash (sha1, sha256 i inne).

Myślę ten silniejszy algorytm przyswajania wiadomości jest koniecznością. Wiadomo, że MD5 I SHA1 mają problemy z kolizją.