Jaka jest optymalna długość soli hasła użytkownika? [Zamknięte]

128

Jakakolwiek sól oczywiście pomoże podczas solenia i haszowania hasła użytkownika. Czy są jakieś najlepsze praktyki dotyczące tego, jak długo powinna trwać sól? Będę przechowywać sól w mojej tabeli użytkowników, więc chciałbym uzyskać najlepszy kompromis między rozmiarem pamięci a bezpieczeństwem. Czy wystarczy 10 losowych soli? A może potrzebuję czegoś dłużej?

encryption hash salt

— David
źródło

10

Nie mam rekomendacji co do długości soli, ale odpowiedzi, które się tutaj pojawiają, zawierają wiele złych informacji. Twoja sól zdecydowanie powinna: - być losowa - znajdować się na kluczu (ani jednej wartości przechowywanej w obrazie programu lub pliku konfiguracyjnym). Sól nie jest tajemnicą kryptograficzną, więc przechowywanie jej w stole nie stanowi problemu. Jedynym celem soli jest zapewnienie, że gdy różne instancje tego samego elementu zostaną zaszyfrowane (lub zaszyfrowane), otrzymasz inny wynik.

— Michael Burr

2

Dla tych, którzy nie wiedzą, czym jest sól: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Sól (kryptografia) </a> na Wikipedii

— David Koelle

1

A może istnieje optymalny stosunek długości soli do długości produkcji haszyszu? 8-bajtowa sól może wystarczyć dla HMAC-SHA-256, ale może nie wystarczyć do HMAC-SHA-512.

— Crend King

1

Kryptograficznie losowa sól o takim samym rozmiarze jak dane wyjściowe funkcji haszującej oznacza, że atak typu „wypróbuj wszystkie możliwe sole” (plus słownik haseł) wymaga tyle samo wysiłku, co atak typu „spróbuj wszystkich możliwych wyników mieszania” - co jest standardową siłą brutalną . Krótsza sól oznacza, że możesz mieć słownik solny i słownik haseł jako atak brutalnej siły.

— Richard Gadsden,

-1 Wprawdzie nie odpowiada (nawet nie próbuje) odpowiedzieć na pytanie.

— user359996

70

Większość z tych odpowiedzi jest nieco błędna i pokazuje pomylenie soli i kluczy kryptograficznych. Celem uwzględnienia soli jest zmodyfikowanie funkcji używanej do skrótu hasła każdego użytkownika, tak aby każdy przechowywany skrót hasła musiał być atakowany indywidualnie. Jedynym wymaganiem dotyczącym bezpieczeństwa jest to, że są one niepowtarzalne dla każdego użytkownika, nie ma żadnej korzyści w tym, że są nieprzewidywalne lub trudne do odgadnięcia.

Sole muszą być tylko wystarczająco długie, aby sól każdego użytkownika była wyjątkowa. Jest bardzo mało prawdopodobne, aby przypadkowe sole 64-bitowe powtórzyły się nawet w przypadku miliarda zarejestrowanych użytkowników, więc powinno być dobrze. Pojedynczo powtórzona sól jest stosunkowo niewielkim zagrożeniem dla bezpieczeństwa, pozwala atakującemu przeszukać dwa konta jednocześnie, ale łącznie nie przyspieszy zbytnio wyszukiwania w całej bazie danych. Nawet 32-bitowe sole są akceptowalne dla większości celów, w najgorszym przypadku przyspieszy to przeszukiwanie atakującego o około 58%. Koszt zwiększenia soli powyżej 64 bitów nie jest wysoki, ale nie ma powodu, aby to robić.

Istnieje pewna korzyść z używania soli dla całej witryny oprócz soli na użytkownika, zapobiegnie to możliwym kolizjom z skrótami haseł przechowywanymi w innych witrynach i zapobiegnie używaniu tabel tęczowych ogólnego przeznaczenia, chociaż nawet 32 bity sól wystarczy, aby tęczowe tablice stały się niepraktycznym atakiem.

Nawet prostsze - a programiści zawsze to przeoczają - jeśli masz unikalne identyfikatory użytkownika lub nazwy logowania, służą one doskonale jako sól. Jeśli to zrobisz, powinieneś dodać sól dla całej witryny, aby upewnić się, że nie pokrywasz się z użytkownikami innego systemu, którzy mieli ten sam błyskotliwy pomysł.

— Bezpieczeństwo Joe
źródło

16

Nieprzewidywalność soli jest korzystna. Można przewidzieć przewidywalną sól i użyć jej w ataku na tablicę mieszającą. Na przykład, jeśli twoja sól to tylko identyfikator użytkownika, wtedy zwykła alfa tablica skrótów, która jest wystarczająco długa, będzie zawierać nie tylko wszystkie hasła, ale wszystkie kombinacje nazwa użytkownika i hasło.

— Richard Gadsden,

6

Zauważ, że w odniesieniu do ostatniego akapitu, jeśli używasz soli dla całej witryny, powinno to być dokładnie to: dla całej witryny. Nie dla całej aplikacji, tj. Każde nowe wystąpienie aplikacji, które instalujesz, powinno generować nową sól dla całej witryny. Na przykład, gdyby system Windows używał tej samej soli w każdej bazie danych uwierzytelniania systemu Windows, warto byłoby utworzyć tęczową tabelę dla tej soli, ale gdyby każda instalacja systemu Windows generowała nową sól, to nie byłoby.

— Richard Gadsden,

5

Problem nie polega na tym, że sól musi być trudna do odgadnięcia. Atakujący nie musi zgadywać soli: każdy, kto ma dostęp do haszyszu, ma już sól. Problem polega na tym, że jeśli twoje sole są bardzo powszechne (jak nazwy użytkowników), mogą być takie same jak te w innych witrynach, a na tym etapie atakujący potrzebuje znacznie mniejszego zestawu tabel tęczowych, aby ataki były wykonalne. Z tego powodu wspomina się o idei soli na lokalizację, aby uniknąć tego rodzaju kolizji z innymi witrynami.

— Nate CK

3

Krótka uwaga: jeśli używasz nazw użytkowników jako soli, może to stanowić problem, jeśli nazwy użytkowników się zmienią. Praktycznie (pomimo tego, co jest powiedziane w dokumentach projektowych klienta) stwierdziłem, że użytkownicy często chcą zmieniać nazwy użytkowników.

— SilentSteel,

5

@ NateC-K, Pomysł na sól w miejscu, o którym mówisz, nazywa się pieprz.

— Pacerier,

35

Obecnie przyjęte standardy haszowania haseł tworzą nową 16-znakową sól dla każdego hasła i przechowują sól z hashem hasła.

Oczywiście należy zadbać o kryptografię, aby stworzyć naprawdę losową sól.

— David Schmitt
źródło

6

Charakter jest trochę źle zdefiniowany. Powinieneś powiedzieć bajt .

— CodesInChaos

10

@CodesInChaos Wierzę, że masz na myśli oktet ;-)

— user2864740

1

Cześć! Wygląda na to, że artykuł na Wikipedii się zmienił - może warto zajrzeć na en.wikipedia.org/wiki/PBKDF2 czy coś?

— Boris Treukhov

5

Lub jeszcze lepiej owasp.org/index.php/Password_Storage_Cheat_Sheet

— Boris Treukhov

24

Edycja: Moja odpowiedź poniżej odpowiedzi na pytanie, jak hasła, ale „prawdziwy” Odpowiedź brzmi: tak Zastosowanie bcrypt , scrypt lub Argon2 . Jeśli zadajesz takie pytania, prawie na pewno używasz narzędzi na zbyt niskim poziomie.

Szczerze mówiąc, nie ma uzasadnionego powodu, aby sól nie miała dokładnie takiej samej długości, jak zaszyfrowane hasło. Jeśli używasz SHA-256, masz 256-bitowy skrót. Nie ma powodu, aby nie używać 256-bitowej soli.

Więcej niż 256 bitów nie zapewni żadnej poprawy bezpieczeństwa matematycznego. Ale wybranie krótszej soli zawsze może skończyć się sytuacją, w której tęczowy stół dogoni twoją długość soli - szczególnie w przypadku krótszych soli.

— Stephen Touset
źródło

10

To nie jest taka wielka sprawa; użytkownik ledwo zauważy różnicę między haszowaniem milisekundowym i półsekundowym, a dodatkowo haszowanie hasła powinno w rzeczywistości zająć więcej czasu, aby spowolnić ataki siłowe - chociaż typowe trzy uderzenia zablokowane na 15 minut są lepsze. Czy „marnujesz” cykle procesora, aby to zrobić? Tak, cokolwiek. Procesor i tak spędza więcej czasu bezczynnie niż w większości witryn internetowych, więc jakie to ma znaczenie? Jeśli masz problemy z wydajnością, skaluj w poziomie.

— Randolpho,

14

Sole chronią przed tęczowymi stołami. 512-bitowa sól z 256-bitowym hashem nadal da tylko 256 bitów entropii w końcowym haśle.

— Stephen Touset

8

Powolne haszowanie to funkcja, a nie błąd.

— outis

7

Jeśli masz 3-bitowy hash, twoja sól 9999-bitowa będzie nadal mieszać tylko do 3 możliwych bitów entropii. Tęczowa tabela musiałaby znaleźć tylko trzy sole dla każdego hasła, które skutkują innym wyjściem, który jest stałym mnożnikiem, a tym samym odrzuca duże-O.

— Stephen Touset

2

.................................................. .................................... konkretnego systemu. Celem soli jest powstrzymanie ataków precomputation tak że hashe nie mogą być wyszukiwane i natychmiast odwrócony w postaci zwykłego tekstu . Dzięki soli 9999-bitowej Twoje hasło pozostaje tajemnicą , podczas gdy w przypadku 3-bitowej soli Twoje hasło jest teraz znane całemu światu (i mogą go używać do logowania się na inne konta, ponieważ wiele osób często ponownie używa haseł). Uważam za zabawne, że 5 osób tutaj faktycznie poparło twój komentarz z powodu słowa „entropia” w nim.

— Pacerier,

7

Wikipedia :

Metody SHA2-crypt i bcrypt - używane w systemach Linux, BSD Unixes i Solaris - mają 128-bitowe sole. Te większe wartości sprawiają, że ataki z obliczeniami wstępnymi dla prawie dowolnej długości hasła są niewykonalne na te systemy w dającej się przewidzieć przyszłości.

Wystarczy sól 128-bitowa (16-bajtowa). Można to przedstawić jako sekwencję 128 / 4 = 32cyfr szesnastkowych.

— Andrii Nemchenko
źródło

Wydaje mi się, że przykład tego, czego używają inne bezpieczne systemy, jest doskonałym przykładem najlepszej praktyki.

— cjbarth

1

@ mklement0 Dzięki, zaktualizowałem odpowiedź.

— Andrii Nemchenko

2

Jedną z odpowiedzi może być użycie jako wielkości soli wartości, którą hash, którego zamierzasz użyć, zapewnia pod względem bezpieczeństwa.

Np. Jeśli zamierzasz używać SHA-512, użyj 256-bitowej soli, ponieważ bezpieczeństwo zapewniane przez SHA-512 wynosi 256 bitów.

— Roberto Martelloni
źródło