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

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?

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

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.

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.

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.

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.