Nieprzypadkowa sól dla hashów haseł

Stosowanie soli o wysokiej entropii jest absolutnie niezbędne do bezpiecznego przechowywania haseł.

Weź moją nazwę użytkownika ' gs 'i dodaj ją do mojego hasła' MyPassword ' daje gsMyPassword. Jest to łatwo złamane przy użyciu tabeli rainbow, ponieważ jeśli nazwa użytkownika nie ma wystarczającej entropii, może być tak, że ta wartość jest już przechowywana w tabeli rainbow, szczególnie jeśli nazwa użytkownika jest krótka.

Kolejnym problemem są ataki, w których wiadomo, że użytkownik uczestniczy w dwóch lub więcej usługach. Tam jest wiele wspólnych nazw użytkowników, prawdopodobnie najważniejsze z nich to admin i root. Jeśli ktoś stworzył tęczową tabelę z najczęściej używanymi nazwami użytkowników, mógłby użyć ich do skompromitowania kont.

Kiedyś mieli 12-bitową sól . 12 bitów to 4096 różnych kombinacji. To nie było wystarczająco bezpieczne, ponieważ tyle informacji można łatwo przechowywać w dzisiejszych czasach . To samo dotyczy 4096 najczęściej używanych nazw użytkowników. Jest prawdopodobne, że kilku użytkowników będzie wybieraj nazwę użytkownika, która należy do najpopularniejszych nazw użytkowników.

Znalazłem ten password checker który sprawdza entropię twojego hasła. Posiadanie mniejszej entropii w hasłach (jak używanie nazw użytkowników) znacznie ułatwia rainbowtables, ponieważ starają się pokryć przynajmniej wszystkie hasła o niskiej entropii, ponieważ są one bardziej prawdopodobne.

Prawdą jest, że sama nazwa użytkownika może być problematyczna, ponieważ ludzie mogą udostępniać nazwy użytkowników między różnymi witrynami. Ale powinno być raczej bezproblemowe, jeśli użytkownicy mieli inną nazwę na każdej stronie. Dlaczego więc nie uczynić go wyjątkowym na każdej stronie internetowej. Hashuj hasło nieco tak

Hashfunction("www.yourpage.com/" + username+" / " +password)

To powinno rozwiązać problem. Nie jestem mistrzem kryptoanalizy, ale wątpię, że nie używamy wysokiej entropii to by osłabiło hash.

Lubię używać obu: wysokiej entropii przypadkowej soli na rekord, plus unikalny identyfikator samego rekordu.

Choć to nie wnosi wiele do bezpieczeństwa przed atakami słownikowymi itp., usuwa przypadek, w którym ktoś kopiuje ich sól i hash do innego rekordu z zamiarem zastąpienia hasła własnym.

(co prawda trudno wymyślić okoliczności, w których to dotyczy, ale nie widzę szkody w paskach i szelkach, jeśli chodzi o Ochrona.)

Jeśli sól jest znana lub łatwo zgadywalna, nie zwiększyłeś trudności ataku słownikowego. Możliwe jest nawet stworzenie zmodyfikowanego tęczowego stołu, który bierze pod uwagę" stałą " sól.

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

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

Powiedziałbym, że dopóki sól jest inna dla każdego hasła, prawdopodobnie będzie ok. Chodzi o to, że nie można użyć standardowej tabeli tęczowej do rozwiązania każdego hasła w bazie danych. Jeśli więc zastosujesz inny salt do każdego hasła (nawet jeśli nie jest to losowe), atakujący będzie musiał w zasadzie obliczyć nową tęczową tabelę dla każdego hasła, ponieważ każde hasło używa innego salt.

Używanie soli z większą entropią nie pomaga w niczym, ponieważ w tym przypadku zakłada się, że osoba atakująca posiada już bazę danych. Ponieważ musisz być w stanie odtworzyć hash, musisz już wiedzieć, co to jest sól. Musisz więc przechowywać sól lub wartości, które składają się na sól w Twoim pliku. W systemach takich jak Linux, metoda uzyskiwania soli jest znana, więc nie ma sensu mieć tajemnej soli. Musisz założyć, że atakujący, który ma twoje wartości hash, prawdopodobnie zna również twoje wartości salt.

Siła funkcji hash nie jest określona przez jej wejście!

Użycie soli, która jest znana atakującemu, oczywiście uatrakcyjnia tworzenie tęczowej tabeli (szczególnie dla ciężko zakodowanych nazw użytkowników, takich jak root ), ale nie osłabia hash. Użycie soli nieznanej atakującemu sprawi, że system będzie trudniejszy do ataku.

Konkatenacja nazwy użytkownika i hasła może nadal stanowić wpis dla inteligentnej tęczowej tabeli, więc użycie soli serii pseudolosowych znaków, przechowywanych z hashowanym hasłem jest chyba lepszym pomysłem. Jako ilustrację, gdybym miał nazwę użytkownika "potato" i hasło "beer", konkatenowane wejście dla Twojego hasha jest "potatobeer", co jest rozsądnym wpisem dla tęczowej tabeli.

Zmiana salt za każdym razem, gdy użytkownik zmienia swoje hasło, może pomóc w pokonaniu długotrwałych ataków, podobnie jak egzekwowanie rozsądnej polityki haseł, np. mieszana wielkość liter, interpunkcja, Długość min, zmienić po N tygodniach.

Jednak powiedziałbym, że wybór algorytmu digest jest ważniejszy. Użycie SHA-512 okaże się bardziej bolesne dla kogoś generującego Tęczowy stół niż MD5, na przykład.

Salt powinien mieć jak najwięcej entropii, aby zapewnić, że jeśli dana wartość wejściowa zostanie zahaszowana wielokrotnie, otrzymana wartość będzie, jak najbliżej, zawsze inna.

Używanie ciągle zmieniających się wartości soli z jak największą entropią w soli zapewni, że prawdopodobieństwo hashowania (np. hasło + sól) wytworzy zupełnie inne wartości hashowania.

Im mniej entropii w soli, tym większa szansa na wytworzenie tej samej soli wartość, ponieważ tym bardziej masz szansę na wygenerowanie tej samej wartości hash.

Natura wartości hash jest "stała", gdy dane wejściowe są znane i "stała", które pozwalają atakom słownikowym lub tablicom tęczowym być tak skuteczne. Zmieniając otrzymaną wartość skrótu tak bardzo, jak to możliwe (używając wysokiej wartości entropii soli) zapewnia, że hashowanie tego samego wejścia+random-salt spowoduje wiele różnych wyników wartości skrótu, tym samym pokonując (lub co najmniej znacznie zmniejszając skuteczność) ataków rainbow table.

Entropia jest punktem wartości soli.

Jeśli za solą kryje się jakaś prosta i powtarzalna "Matematyka", to znaczy, że soli nie ma. Samo dodawanie wartości czasu powinno być w porządku.