Solenie hasła: najlepsze praktyki?

Zawsze byłem ciekawy ... Co jest lepsze, gdy zasolisz hasło do haszowania: prefiks czy postfiks? Czemu? Czy to ma znaczenie, jeśli solisz?

Aby wyjaśnić: Wszyscy (miejmy nadzieję) już wiemy, że powinniśmy posolić hasło, zanim zaszyfrujemy je do przechowywania w bazie danych [ Edycja: Więc możesz uniknąć rzeczy takich jak to, co ostatnio przytrafiło się Jeffowi Atwoodowi ]. Zwykle odbywa się to przez połączenie soli z hasłem przed przekazaniem go przez algorytm haszujący. Ale przykłady są różne ... Niektóre przykłady poprzedzają sól przed hasłem. Niektóre przykłady dodają sól po haśle. Widziałem nawet takich, którzy próbowali umieścić sól na środku.

Więc która metoda jest lepsza i dlaczego? Czy istnieje metoda zmniejszająca ryzyko kolizji hash? Moje Googlowanie nie znalazło przyzwoitej analizy na ten temat.

Edycja: świetne odpowiedzi, ludzie! Przepraszam, że mogłem wybrać tylko jedną odpowiedź. :)

Prefiks lub sufiks jest nieistotny, chodzi tylko o dodanie do hasła entropii i długości.

Powinieneś rozważyć te trzy rzeczy:

1. Sól musi być inna dla każdego przechowywanego hasła. (To dość powszechne nieporozumienie.)
2. Użyj bezpiecznego kryptograficznie generatora liczb losowych.
3. Wybierz wystarczająco długą sól. Pomyśl o problemie urodzinowym.

Jest doskonała odpowiedź Dave'a Sherohmana na inne pytanie, dlaczego powinieneś używać losowo generowanych soli zamiast nazwy użytkownika (lub innych danych osobowych). Jeśli zastosujesz się do tych sugestii, naprawdę nie ma znaczenia, gdzie włożysz sól.

Myślę, że to wszystko semantyka. Umieszczenie go przed lub po nie ma znaczenia, z wyjątkiem bardzo konkretnego modelu zagrożenia.

Fakt, że tam jest, ma pokonać tęczowe tablice.

Model zagrożenia, do którego nawiązywałem, byłby scenariuszem, w którym przeciwnik może mieć tęczowe tabele soli pospolitych dołączane / poprzedzane do hasła. (Powiedz NSA) Zgadujesz, że albo mają to dołączone, albo poprzedzone, ale nie oba. To głupie i kiepskie przypuszczenie.

Lepiej byłoby założyć, że mają możliwość przechowywania tych tęczowych tabel, ale nie, powiedzmy, tabel z dziwnymi solami przeplatanymi w środku hasła. W tej wąskiej przypadku, chciałbym przypuszczać, że przeplatane będzie najlepiej.

Tak jak powiedziałem. To semantyka. Wybierz inną sól dla hasła, długą sól i umieść w niej dziwne znaki, takie jak symbole i kody ASCII: © ¤¡

Prawdziwa odpowiedź, której nikt chyba nie poruszył, jest taka, że obie są w błędzie . Jeśli wdrożenie własnego kryptograficznych, nie ważne jak błahe część myślisz robisz, to idą do popełniania błędów.

HMAC to lepsze podejście, ale nawet jeśli używasz czegoś takiego jak SHA-1, już wybrałeś algorytm, który nie nadaje się do haszowania haseł ze względu na jego projekt pod kątem szybkości. Użyj czegoś takiego jak bcrypt lub prawdopodobnie scrypt i całkowicie usuń problem z rąk.

Aha, i nawet nie myśl o porównywaniu wynikowych skrótów dla równości z językiem programowania lub narzędziami do porównywania ciągów bazy danych. Porównują znak po znaku i zwierają, falsejakby znak był inny. Więc teraz atakujący mogą używać metod statystycznych, aby spróbować ustalić, czym jest skrót, znak po znaku.

To nie powinno mieć żadnego znaczenia. Hasz nie będzie łatwiejszy do odgadnięcia, gdziekolwiek umieścisz sól. Zderzenia skrótów są zarówno rzadkie, jak i nieprzewidywalne, ponieważ są celowo nieliniowe. Gdyby miało to wpływ na bezpieczeństwo, oznaczałoby to problem z haszowaniem, a nie soleniem.

Jeśli używasz kryptograficznie bezpiecznego skrótu, nie powinno mieć znaczenia, czy wykonujesz prefiks czy postfiks; punkt haszowania polega na tym, że zmiana jednego bitu w danych źródłowych (bez względu na to, gdzie) powinna dać inny hash.

Co jest ważne, choć jest za pomocą długich soli, wytwarzając je z odpowiednim PRNG kryptograficznego, a po sole poszczególnych użytkowników. Przechowywanie sole poszczególnych użytkowników w bazie danych to nie to kwestia bezpieczeństwa, stosując w całej witrynie hash jest .

Po pierwsze, termin „stół tęczowy” jest konsekwentnie nadużywany. Tablica „tęczowa” jest po prostu szczególnym rodzajem tabeli przeglądowej, która umożliwia określony rodzaj kompresji danych na klawiszach. Zamieniając obliczenia na miejsce, tabelę wyszukiwania, która zajęłaby 1000 TB, można skompresować tysiąc razy, aby można ją było przechowywać na mniejszym dysku.

Powinieneś się martwić o hash do tabel wyszukiwania haseł, tęczy lub w inny sposób.

@ onebyone.livejournal.com:

Atakujący ma „tęczowe tablice” składające się nie z skrótów słów ze słownika, ale ze stanu obliczenia skrótu tuż przed zakończeniem obliczania skrótu.

Wówczas tańsze byłoby wymuszenie brutalnego wpisu w pliku z hasłem za pomocą soli postfiksowej niż sól przedrostka: dla każdego słowa ze słownika z kolei ładowałbyś stan, dodawał bajty soli do skrótu, a następnie finalizował. Z przedrostkiem sól nie byłoby nic wspólnego między obliczeniami dla każdego słowa słownikowego.

W przypadku prostej funkcji skrótu, która skanuje liniowo ciąg wejściowy, na przykład prosty generator liniowy kongruencji, jest to praktyczny atak. Ale kryptograficznie bezpieczna funkcja skrótu jest celowo zaprojektowana tak, aby miała wiele rund, z których każda wykorzystuje wszystkie bity ciągu wejściowego, więc obliczenie stanu wewnętrznego tuż przed dodaniem soli nie ma sensu po pierwszej rundzie. Na przykład SHA-1 ma 80 rund.

Ponadto algorytmy haszujące hasła, takie jak PBKDF, tworzą swoją funkcję skrótu wielokrotnie (zaleca się iterację PBKDF-2 minimum 1000 razy, każda iteracja dwukrotnie stosuje SHA-1), czyniąc ten atak podwójnie niepraktycznym.

Skrót BCrypt, jeśli platforma ma dostawcę. Uwielbiam to, jak nie martwisz się tworzeniem soli i możesz je wzmocnić, jeśli chcesz.

Wstawienie soli dowolnej liczby znaków do hasła jest najmniej oczekiwanym przypadkiem, a zatem jest najbardziej „bezpiecznym” społecznie, ale w ogólnym przypadku nie ma to większego znaczenia, o ile używasz długiego unikalnego hasła sznurki do soli.