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

89

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).

Zachłanny
źródło
Muszę powiedzieć, że wiele z poniższych odpowiedzi mnie zdezorientowało. Głównym celem używania soli jest po prostu zapobieganie atakowi tęczowego stołu, więc wszystko, co jest unikalne dla użytkownika, powinno zrobić, ponieważ zmusza atakującego do odtworzenia tęczowego stołu dla każdej soli. mój 2c.
Goran
Jeśli sól jest potrzebna np. witryna, często masz identyfikatory w adresach URL. Jeśli atakujący wie (i zakładamy, że wie), że sól hasła to identyfikator użytkownika + nazwa użytkownika, dość łatwo jest zmodyfikować atak, aby uniknąć wartości soli.
dmajkic
@dmajkic, salt ma na celu zapobieganie atakom RT i rozróżnianie tych samych haseł dla różnych użytkowników. To jest dane, nawet w przypadku nazw użytkowników.
AviD
@AviD: To prawda. Ale jeśli znam swój hash dla mojego hasła i wiem, że sól jest moją nazwą użytkownika, mogę łatwo utworzyć zaszyfrowaną wartość hasła dla dowolnego słowa ze słownika i porównać ją z hashem innego hasła. Dlatego czas jest lepszy niż nazwa użytkownika.
dmajkic
1
Właśnie znalazłem artykuł na stronie PHP Security Consortium, który w swoim przykładzie używa haszowanej losowej liczby md5 jako sól phpsec.org/articles/2005/password-hashing.html
helloworlder

Odpowiedzi:

156

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.

Dave Sherohman
źródło
Zgoda. Położyłbym większy nacisk na ponowne użycie nazw użytkowników, ponieważ myślę, że jest to atak z największym prawdopodobieństwem udany przeciwko hipotetycznym systemom używającym nazwy użytkownika jako soli, które nie powiodłyby się w przypadku systemu używającego losowej soli.
Steve Jessop
Doceniam twój punkt widzenia na bezpieczeństwo międzysystemowe.
Wydaje
@AviD: Tak myślisz? To dość specyficzny wektor ataku.
David Grant
2
Nie do wytwarzania soli, nie. Jedynymi atakami, na które ma wpływ sól, są te wykonywane bezpośrednio przeciwko zaszyfrowanym hasłom. Atak nie może wykonać tego rodzaju ataku, chyba że ma kopię bazy danych haseł, która będzie również zawierać sole. Ponieważ atakujący będzie już posiadał sole w swoim posiadaniu, wymagają one jedynie wystarczającej entropii, aby uniknąć posiadania wielu haseł zaszyfrowanych tą samą solą, którą zapewni każdy podstawowy (P) RNG.
Dave Sherohman
3
@ acidzombie24: Używanie jednej ustalonej soli (z mojego doświadczenia zwykle nazywanej „nonce”) dla wszystkich haseł jest mniej bezpieczne niż użycie unikalnej, losowej soli dla każdego hasła, ponieważ nadal pozwala atakującemu na trywialne określenie, czy dwa lub więcej kont współdzielą to samo hasło. Z drugiej strony, numer jednorazowy prawdopodobnie byłby przechowywany w twoim kodzie, a nie w bazie danych, więc osoba atakująca, która ma tylko twoją bazę danych, nie będzie miała do niej dostępu; z tego powodu najbezpieczniejszą opcją jest użycie zarówno wartości nonce dla całego systemu (przechowywanej w kodzie), jak i soli dla hasła (przechowywanej w bazie danych).
Dave Sherohman
29

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.

Georg Schölly
źródło
+1 punkt za dobrą, jednak ty się mówić o potencjalnie masywnym stołem tęczy. Aby zakryć wszystkie wartości długości gsMyPassword (przy założeniu, że znaki alfanumeryczne mają różne wielkości liter) wymaga 36 ^ 12 wierszy w tabeli!
David Grant
W ramach kontynuacji: projekt rozproszonego stołu tęczowego ma 63 970 pękniętych skrótów, ale 36 ^ 12 to 4 738 381 338 322 616 896!
David Grant
Dzięki, i to ma sens - ale jak zauważył Pan PotatoHead, nadal rozszerzasz swoją przestrzeń poza rozsądną możliwość pękania za pomocą RT. Zakładając również, że moje nazwy użytkowników mają co najmniej 6-8 znaków - jaką dodatkową niezbędną wartość zapewnia entropia?
AviD
@Potato: zakładasz tęczową tabelę zawierającą wszystkie możliwe kombinacje znaków alfanumerycznych. Nie musi tak być, efektywna tablica tęczowa będzie zawierać skróty dla popularnych haseł / skrótów. Sól ma chronić przed atakami słownikowymi lub połączoną tęczową tabelą / słownikiem.
Guillaume
3
Używanie nazwy użytkownika jako soli jest również złym pomysłem w systemach, w których istnieje przewidywalnie nazwane konto o wysokich uprawnieniach: „Administrator” w systemie Windows, „root” na * nix, „sa” w MSSQL itp.
nikt
8

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.

konne
źródło
Uważam, że masz rację, że to wystarczy. Biorąc jednak pod uwagę, że hasze są skomplikowaną dziedziną matematyczną i jest bardzo prawdopodobne, że sole o niskiej entropii ułatwiają odgadywanie haszów w przyszłości (zwłaszcza, gdy hashe się psują), nie stawiam na bezpieczeństwo, gdy bezpieczniejsze rozwiązanie nie jest dużo droższe.
Georg Schölly,
7

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.

teedyay
źródło
Podoba mi się pomysł powiązania hasła z użytkownikiem. Ale jeśli atakujący może zmienić hasło, z pewnością może również zmienić identyfikator.
Georg Schölly
Zależy od tego, jaki jest identyfikator: używam klucza podstawowego tabeli, którego tak naprawdę nie można zmienić do woli. TBH, jeśli haker pisze do twojej bazy danych, masz już dość duże kłopoty ...
teedyay
3
Nie, podoba mi się. Atakujący jest często „insiderem”. Mógłbym wymyślić scenariusze, w których tego, czego szuka, nie ma w bazie danych, ale jeśli może nadpisać dane uwierzytelniające w bazie danych, może uwierzytelnić się, aby robić, co chce.
erickson
1
Słuszna uwaga. Uważamy, że coraz trudniej jest dodać pierwszego użytkownika do nowej bazy danych: skutecznie sprawiliśmy, że nasze aplikacje są tak bezpieczne, że ledwo możemy je zhakować. [Ponadto użyj soli specyficznej dla aplikacji, aby nie można było kopiować poświadczeń z jednej bazy danych do drugiej.]
teedyay,
Wreszcie znalazłem kogoś, kto mówił tak: dodawał do soli coś specyficznego dla użytkownika. Pozwala to uniknąć przekopiowania przez intruza niektórych danych uwierzytelniających do innego użytkownika, a także uniemożliwia hakerowi odgadnięcie hasła, jeśli uda mu się dotrzeć do twojego pola hash i soli w tabeli. Jeszcze jedna rzecz, którą lubię robić: nie używać okrągłej liczby iteracji w haszowaniu. Nie idź za 10 000 lub 20 000, ale raczej coś w stylu 19835.
Andrew
3

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.

HUAGHAGUAH
źródło
2
Cały punkt tęczy tabeli polega na tym, że wartości są generowane wstępnie i że jeśli generujesz tabelę dla wartości (np. Hasła) PLUS danej stałej, to jest to zupełnie inna tabela, i równie dobrze możesz po prostu wypróbuj wynik skrótu bezpośrednio. :)
David Grant
1
Stały hash nie jest nic wart. Wszystkie hasła można złamać za pomocą jednej tęczowej tabeli. Zadaniem soli jest to, że niemożliwe jest stworzenie tęczowego stołu.
Georg Schölly
1
@gs - Nie rozumiem, dlaczego nie możesz zbudować tęczowego stołu, który „zawiera” efekty stałej soli. Przestrzeń ataku (hasło) nie ulegnie zmianie, więc tabela nie będzie musiała rosnąć, wystarczy ją przeliczyć.
HUAGHAGUAH
@Potato - zależy od kompromisu. Jeśli wszystkie 20 tys. Logowań Twojej firmy zostały zaszyfrowane przy użyciu tej samej stałej soli, taniej może być obliczenie nowej tęczowej tabeli niż atakowanie ich za pomocą słownika indywidualnie. Stąd mój nacisk na „BULK”.
HUAGHAGUAH
3

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.

Kibbee
źródło
3
„Rzecz w tym, że nie można użyć standardowej tabeli tęczowej do rozwiązania każdego hasła w bazie danych”. Nie zgadzam się. Chodzi o to, że nie możesz użyć standardowej tęczowej tabeli do rozwiązania żadnego hasła. Jeśli nazwa użytkownika to sól, to tablica tęczowa dla „root” może złamać pw roota.
Steve Jessop
To prawdopodobnie jedyna zasada, która naprawdę ma znaczenie. Zasadniczo chcesz, aby hasło było unikalne w Twoim systemie, ale nie ma znaczenia, jakie ono jest. Jednak nadal może to być coś prostego. Nie potrzebujesz dużo entropii.
Kibbee
To też było moje myślenie - ale utknąłem na „prawdopodobnie w porządku”. Nadal nie widzę, aby ta teoria została udowodniona - lub przynajmniej zweryfikowana, że ​​nie ma implikacji kryptoanalizy.
AviD
@onebyone: Jeśli sól składa się z nazwy użytkownika + stałej wartości lokalnej (często używam ':'), to nadal rujnuje standardowe RT, chyba że istnieje wiele z nich, które zawierają wspólne nazwy użytkowników i wspólne statyczne wartości soli. Podejrzewam, że tak nie jest.
nsayer
Wraz z nsayer. Możesz użyć stałego ciągu całego systemu, dla którego nie byłoby wstępnie wygenerowanego RT, takiego jak # (D83d8, wraz z nazwą użytkownika jako sól, a to prawdopodobnie zapobiegałoby atakom tęczowej tablicy.
Kibbee
3

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.

David Grant
źródło
Siła funkcji się nie zmienia, ale wyjście zdecydowanie się zmienia. Jeśli na dane wejściowe można wpływać lub je znać, być może można coś wywnioskować o wartości skrótu. To jest ryzyko.
Martin Carpenter
@Martin: Jedyną rzeczą, którą powinieneś być w stanie wywnioskować z wartości skrótu, jeśli masz dopasowanie, czy nie! Umieszczenie "roota" lub "rootb" (gdzie "a" i "b" reprezentują hasło) do funkcji haszującej da radykalnie inny wynik.
David Grant
Sole są znane napastnikowi za pomocą tęczowych tablic.
Georg Schölly
Serwer musi znać niezaszyfrowaną sól (aby sprawdzić hasło przed hashem), więc można przyjąć za pewnik, że atakujący ma dostęp do soli lub może ją bardzo łatwo zdobyć.
Georg Schölly
Racja, racja, to jest dane - mówiąc dokładniej, miałem na myśli siłę całego kryptosystemu (lub -subsystem, wrt hashes).
AviD
1

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.

CraigTP
źródło
Ponownie, nie mówię o użyciu jednej stałej soli - raczej nielosowej, ale unikalnej dla użytkownika wartości. Np. UserId.
AviD
Chodzi o to, że twoja wartość soli nigdy nie powinna być stała. Każda rzecz, którą haszujesz, niezależnie od tego, czy ta sama wartość „wejściowa”, czy nie, powinna mieć inną sól. Dave Sherohman wyjaśnia wady używania nawet wartości unikalnych dla użytkownika, które zasadniczo pozostają takie same przy każdym obliczeniu skrótu.
CraigTP
-1

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ć.

dmajkic
źródło
Nie rozumiem tego komentarza. Mówisz „użyj entropii”, a potem: „użyj czasu”?
Martin Carpenter,
jeśli nazwa użytkownika jest używana dla soli, to nie jest wystarczająco entropiczna. Ale jeśli używasz nazwy użytkownika + aktualna data - tak jest, ponieważ trudno odgadnąć, kiedy dokładnie powstała sól.
dmajkic
„dostatecznie entropiczny” jest subiektywny; to twój standard. Oparcie tej wartości na czasie może nie być wystarczające.
Martin Carpenter,
Nie ma czegoś takiego jak „absolutna prawdziwa losowość”. Naszym zadaniem jest powiedzenie, kiedy jest „wystarczająco dobre”. Jeśli uważasz, że w tym przypadku czas nie jest wystarczająco dobry, użyj czegoś innego. stackoverflow.com/questions/84556/…
dmajkic
W rzeczywistości chodzi o to, aby każdy wynik haszowania był niepowtarzalny - aby zapobiec (a) atakom tęczowej tablicy i (b) identycznej identyfikacji hasła. Pytanie brzmi, po co jeszcze jest potrzebna entropia, jeśli w ogóle?
AviD