Nielosowa sól dla skrótów haseł

AKTUALIZACJA: Niedawno dowiedziałem się z tego pytania, że w całej dyskusji poniżej ja (i jestem pewien, że inni też) byłem nieco zagmatwany: to, co wciąż nazywam tęczowym stołem, tak naprawdę nazywa się tablicą mieszającą. Tęczowe stoły są bardziej złożonymi stworzeniami i są w rzeczywistości wariantem Hellman Hash Chains. Chociaż uważam, że odpowiedź jest nadal taka sama (ponieważ nie sprowadza się ona do kryptoanalizy), część dyskusji może być nieco wypaczona.
Pytanie: „ Co to są tęczowe tablice i jak są używane? ”

Zwykle zawsze zalecam użycie silnej kryptograficznie wartości losowej jako soli, która ma być używana z funkcjami skrótu (np. Do haseł), na przykład w celu ochrony przed atakami Rainbow Table.

Ale czy rzeczywiście kryptograficznie konieczne jest, aby sól była losowa? Czy jakakolwiek unikalna wartość (unikalna dla użytkownika, np. UserId) byłaby wystarczająca w tym zakresie? W rzeczywistości uniemożliwiłoby to użycie jednej Rainbow Table do złamania wszystkich (lub większości) haseł w systemie ...
Ale czy brak entropii naprawdę osłabia siłę kryptograficzną funkcji skrótu?

Uwaga, nie pytam o to, dlaczego używać soli, jak ją chronić (nie musi), używając pojedynczego stałego skrótu (nie), ani jakiego rodzaju funkcji skrótu użyć.
Tylko czy sól potrzebuje entropii, czy nie.

Dziękuję wszystkim za dotychczasowe odpowiedzi, ale chciałbym skupić się na obszarach, które (trochę) mniej znam. Głównie implikacje dla kryptoanalizy - byłbym wdzięczny najbardziej, gdyby ktoś miał jakiś wkład z krypto-matematycznego punktu widzenia.
Ponadto, jeśli istnieją dodatkowe wektory, które nie były brane pod uwagę, to również jest świetny wkład (patrz punkt @Dave Sherohman na temat wielu systemów).
Poza tym, jeśli masz jakąkolwiek teorię, pomysł lub najlepszą praktykę - poprzyj to dowodem, scenariuszem ataku lub dowodami empirycznymi. Lub nawet ważne rozważania na temat akceptowalnych kompromisów ... Znam najlepsze praktyki (duże B, duże P) w tym temacie, chciałbym udowodnić, jaką wartość to faktycznie zapewnia.

EDYCJA: Kilka naprawdę dobrych odpowiedzi, ale myślę, że jak mówi @Dave, sprowadza się to do Rainbow Tables dla typowych nazw użytkowników ... i prawdopodobnie mniej popularnych nazw. A co, jeśli moje nazwy użytkownika są unikalne w skali globalnej? Niekoniecznie unikalne dla mojego systemu, ale dla każdego użytkownika - np. Adres e-mail.
Nie byłoby zachęty do budowania RT dla pojedynczego użytkownika (jak podkreślił @Dave, sól nie jest utrzymywana w tajemnicy), a to nadal zapobiegałoby tworzeniu się klastrów. Jedynym problemem byłoby to, że mógłbym mieć ten sam adres e-mail i hasło na innej stronie - ale sól i tak by temu nie zapobiegła.
Wracamy więc do kryptoanalizy - czy entropia jest konieczna, czy nie? (Obecnie sądzę, że nie jest to konieczne z punktu widzenia kryptoanalizy, ale wynika to z innych praktycznych powodów).

Sól jest tradycyjnie przechowywana jako przedrostek zaszyfrowanego hasła. Dzięki temu jest już znany każdemu atakującemu, który ma dostęp do skrótu hasła. Używanie nazwy użytkownika jako soli lub nie ma wpływu na tę wiedzę, a zatem nie miałoby wpływu na bezpieczeństwo pojedynczego systemu.

Jednak użycie nazwy użytkownika lub jakiejkolwiek innej wartości kontrolowanej przez użytkownika jako soli zmniejszyłoby bezpieczeństwo międzysystemowe, ponieważ użytkownik, który miał tę samą nazwę użytkownika i hasło w wielu systemach, które używają tego samego algorytmu mieszania haseł, skończyłby z tym samym skrótem hasła na każdy z tych systemów. Nie uważam tego za poważną odpowiedzialność, ponieważ jako osoba atakująca próbowałbym najpierw wypróbować hasła, o których wiadomo, że konto docelowe użyło w innych systemach, zanim podejmiemy jakiekolwiek inne sposoby naruszenia konta. Identyczne skróty informowałyby mnie z góry tylko o tym, że znane hasło będzie działać, a nie ułatwią samego ataku. (Należy jednak zauważyć, że szybkie porównanie baz danych kont dostarczyłoby listę celów o wyższym priorytecie, ponieważ powiedziałoby mi, kto jest, a kto nie używa ponownie haseł).

Większym niebezpieczeństwem wynikającym z tego pomysłu jest to, że nazwy użytkownika są często ponownie wykorzystywane - na przykład każda witryna, którą chcesz odwiedzić, będzie miała konto użytkownika o nazwie „Dave”, a „admin” lub „root” są jeszcze bardziej powszechne - co spowodowałoby, że budowa tęczowych tabel skierowanych do użytkowników o tych potocznych nazwach jest znacznie łatwiejsza i skuteczniejsza

Obie te wady można skutecznie rozwiązać, dodając drugą wartość soli (ustaloną i ukrytą lub ujawnioną jak standardowa sól) do hasła przed jego zhaszowaniem, ale w tym momencie równie dobrze możesz po prostu użyć standardowej soli entropicznej. pracy z nazwą użytkownika.

Edytowano, by dodać: Wiele osób mówi o entropii io tym, czy entropia w soli jest ważna. Tak jest, ale nie z tego powodu większość komentarzy na ten temat wydaje się myśleć.

Wydaje się, że ogólna myśl jest taka, że ​​entropia jest ważna, więc sól będzie trudna do odgadnięcia przez napastnika. Jest to niepoprawne i właściwie całkowicie nieistotne. Jak już kilkakrotnie wskazywali różne osoby, ataki, na które wpłynie sól, może wykonać tylko osoba posiadająca bazę danych haseł, a osoba posiadająca bazę haseł może po prostu sprawdzić, jaka jest sól każdego konta. To, czy można to zgadnąć, czy nie, nie ma znaczenia, kiedy można to w trywialny sposób sprawdzić.

Powodem, dla którego entropia jest ważna, jest unikanie grupowania wartości soli. Jeśli sól jest oparta na nazwie użytkownika i wiesz, że większość systemów będzie miała konto o nazwie „root” lub „admin”, możesz utworzyć tęczową tabelę dla tych dwóch soli, która złamie większość systemów. Z drugiej strony, jeśli używana jest losowa 16-bitowa sól, a losowe wartości mają z grubsza równomierny rozkład, wówczas potrzebna jest tablica tęczy dla wszystkich 2 ^ 16 możliwych soli.

Nie chodzi o to, aby atakujący nie wiedział, czym jest sól na koncie indywidualnym, chodzi o to, aby nie dawać mu dużego, tłustego celu w postaci pojedynczej soli, która zostanie użyta na znacznej części potencjalnych celów.

Używanie soli o wysokiej entropii jest absolutnie konieczne do bezpiecznego przechowywania haseł.

Weź moją nazwę użytkownika „gs” i dodaj ją do mojego hasła „Moje hasło” daje gsMyPassword. Można to łatwo zepsuć za pomocą rainbow-table, ponieważ jeśli nazwa użytkownika nie ma wystarczającej entropii, może to oznaczać, że ta wartość jest już przechowywana w rainbow-table, zwłaszcza jeśli nazwa użytkownika jest krótka.

Innym problemem są ataki, w przypadku których wiadomo, że użytkownik uczestniczy w dwóch lub więcej usługach. Istnieje wiele popularnych nazw użytkowników, prawdopodobnie najważniejsze z nich to admin i root. Gdyby ktoś stworzył tęczową tabelę, która zawiera sole z najpopularniejszymi nazwami użytkowników, mógłby użyć ich do włamania na konta.

Kiedyś mieli sól 12-bitową . 12 bitów to 4096 różnych kombinacji. Nie było to wystarczająco bezpieczne, ponieważ obecnie tak wiele informacji można łatwo przechowywać . To samo dotyczy 4096 najczęściej używanych nazw użytkowników. Jest prawdopodobne, że kilku użytkowników wybierze nazwę użytkownika należącą do najpopularniejszych nazw użytkowników.

Znalazłem narzędzie do sprawdzania haseł, które oblicza entropię hasła. Mniejsza entropia w hasłach (na przykład przy użyciu nazw użytkowników) znacznie ułatwia tęczowe tabele, które próbują pokryć przynajmniej wszystkie hasła niską entropią, ponieważ są bardziej prawdopodobne.

Prawdą jest, że sama nazwa użytkownika może być problematyczna, ponieważ ludzie mogą udostępniać nazwy użytkowników na różnych stronach internetowych. Ale nie powinno być problemu, gdyby użytkownicy mieli różne nazwy w każdej witrynie. Dlaczego więc nie uczynić go wyjątkowym w każdej witrynie. Hash hasło mniej więcej w ten sposób

funkcja skrótu („www.twoja strona.com /” + nazwa użytkownika + „/” + hasło)

To powinno rozwiązać problem. Nie jestem mistrzem kryptoanalizy, ale na pewno wątpię, czy fakt, że nie używamy wysokiej entropii, osłabiłby hasz.

Lubię używać obu: losowej soli na każdy rekord o wysokiej entropii oraz unikalnego identyfikatora samego rekordu.

Chociaż nie zwiększa to zbytnio bezpieczeństwa przed atakami słownikowymi itp., Usuwa marginesowy przypadek, w którym ktoś kopiuje swoją sól i hash do innego rekordu z zamiarem zastąpienia hasła własnym.

(Trzeba przyznać, że trudno jest wymyślić okoliczności, w których to ma zastosowanie, ale nie widzę żadnej szkody w pasach i szelkach, jeśli chodzi o bezpieczeństwo.

Jeśli sól jest znana lub łatwa do odgadnięcia, nie zwiększyłeś trudności ataku słownikowego. Możliwe jest nawet stworzenie zmodyfikowanej tabeli tęczowej, która uwzględnia „stałą” sól.

Używanie unikalnych soli zwiększa trudność ataków słownikowych BULK.

Posiadanie unikalnej, silnej kryptograficznie wartości soli byłoby idealne.

Powiedziałbym, że tak długo, jak sól jest inna dla każdego hasła, prawdopodobnie będzie dobrze. Chodzi o to, że nie możesz użyć standardowej tabeli tęczowej do rozwiązania każdego hasła w bazie danych. Więc jeśli zastosujesz inną sól do każdego hasła (nawet jeśli nie jest to losowe), atakujący musiałby w zasadzie obliczyć nową tęczową tabelę dla każdego hasła, ponieważ każde hasło używa innej soli.

Używanie soli o większej entropii nie pomaga zbytnio, ponieważ w tym przypadku zakłada się, że atakujący ma już bazę danych. Ponieważ musisz być w stanie odtworzyć haszysz, musisz już wiedzieć, czym jest sól. Więc musisz przechowywać sól lub wartości, które składają się na sól w twoim pliku. W systemach takich jak Linux znana jest metoda uzyskiwania soli, więc posiadanie tajemnej soli nie ma sensu. Musisz założyć, że napastnik, który ma twoje wartości skrótu, prawdopodobnie zna również twoje wartości soli.

Siła funkcji skrótu nie jest określana przez jej dane wejściowe!

Korzystanie z soli znanej atakującemu w oczywisty sposób sprawia, że ​​tworzenie tęczowej tabeli (szczególnie w przypadku zakodowanych na stałe nazw użytkowników, takich jak root ), jest bardziej atrakcyjne, ale nie osłabia to hasha . Użycie soli nieznanej atakującemu utrudni atak na system.

Połączenie nazwy użytkownika i hasła może nadal zapewniać wpis dla inteligentnej tęczowej tabeli, więc użycie soli serii pseudolosowych znaków, przechowywanych wraz z zakodowanym hasłem, jest prawdopodobnie lepszym pomysłem. Przykładowo, gdybym miał nazwę użytkownika „ziemniak” i hasło „piwo”, połączonym wejściem dla twojego hasha jest „potatobeer”, co jest rozsądnym wpisem dla tęczowego stołu.

Zmiana soli za każdym razem, gdy użytkownik zmienia hasło, może pomóc w pokonaniu przedłużających się ataków, podobnie jak egzekwowanie rozsądnej polityki dotyczącej haseł, np. Mieszana wielkość liter, interpunkcja, minimalna długość, zmiana po n tygodniach.

Jednak powiedziałbym, że ważniejszy jest wybór algorytmu skrótu. Na przykład użycie SHA-512 okaże się bardziej uciążliwe dla kogoś generującego tęczowy stół niż na przykład MD5.

Sól powinna mieć jak największą entropię, aby zapewnić, że w przypadku wielokrotnego haszowania danej wartości wejściowej wynikowa wartość skrótu będzie, tak blisko, jak to tylko możliwe, zawsze różna.

Używanie ciągle zmieniających się wartości soli z możliwie największą entropią w soli zapewni, że prawdopodobieństwo haszowania (powiedzmy, hasło + sól) da zupełnie inne wartości skrótu.

Im mniej entropii w soli, tym większa szansa na wygenerowanie tej samej wartości soli, a tym samym większa szansa na wygenerowanie tej samej wartości skrótu.

To właśnie natura wartości skrótu jest „stała”, gdy dane wejściowe są znane i „stałe”, co umożliwia tak skuteczne ataki słownikowe lub tęczowe tablice. Zmieniając wynikową wartość skrótu tak bardzo, jak to możliwe (używając wysokich wartości soli entropii), zapewnia, że ​​haszowanie tego samego wejścia + losowa sól da wiele różnych wyników wartości skrótu, pokonując w ten sposób (lub przynajmniej znacznie zmniejszając skuteczność) tęczowego stołu ataki.

Entropia jest punktem wartości Soli.

Jeśli za solą kryje się jakaś prosta i powtarzalna „matematyka”, to jest taka sama, jak nie ma soli. Samo dodanie wartości czasu powinno wystarczyć.