Hasło: Najlepsze Praktyki?

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

Model zagrożenia, do którego nawiązałem, byłby scenariuszem, w którym przeciwnik Może mieć do hasła dołączone/dołączone tabele potocznych soli. (Powiedzmy NSA) zgadujesz, że albo mają to dopisane, albo dodane, ale nie jedno i drugie. To głupie i kiepskie przypuszczenie.

Lepiej 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 tym wąskim przypadku, przypuszczam, że przeplatanie byłoby najlepsze.

Jak mówiłem. To semantyka. Wybierz inną sól na hasło, długą sól i dołącz do niej dziwne znaki, takie jak Symbole i kody ASCII: © ¤¡

Prawdziwa odpowiedź, której nikt chyba nie dotknął, jest taka, że obie są złe . Jeśli wdrażasz własną krypto, bez względu na to, jak trywialną część myślisz, że robisz, zamierzasz popełniać błędy.

HMAC jest lepszym podejściem, ale nawet wtedy, jeśli używasz czegoś takiego jak SHA-1, już wybrałeś algorytm, który nie nadaje się do hashowania haseł ze względu na jego konstrukcję dla szybkości. Użyj czegoś w rodzaju bcrypt lub ewentualnie scrypt i wyjmij problem z rąk całkowicie.

Oh, I nawet nie myśl o porównywaniu wynikowych hashów dla równości z twoim językiem programowania lub narzędziami do porównywania łańcuchów baz danych. Te porównują znak po znaku i zwarcie jako false, jeśli znak różni się. Więc teraz atakujący mogą używać metod statystycznych, aby spróbować i dowiedzieć się, co to jest hash, znak na raz.

To nie powinno robić żadnej różnicy. Hash nie będzie łatwiej zgadnąć, gdziekolwiek umieścisz sól. Kolizje Hash są rzadkie i nieprzewidywalne, ponieważ są celowo nieliniowe. Jeśli to coś zmieni dla bezpieczeństwa, to sugerowałoby problem z mieszaniem, a nie soleniem.

Jeśli używasz kryptograficznie bezpiecznego hasha, nie powinno mieć znaczenia, czy pre - czy postfix; punktem hashowania jest to, że pojedyncza zmiana bitu w danych źródłowych (bez względu na to, gdzie) powinna wytworzyć inny hash.

Co jest ważne jest jednak używanie długich soli, generowanie ich za pomocą odpowiedniego kryptograficznego PRNG i posiadanie soli dla użytkownika. Przechowywanie soli per-user w bazie danych jest , a nie problemem bezpieczeństwa, użycie hash jest .

Po pierwsze, termin" Tęczowy stół " jest konsekwentnie nadużywany. Tabela "rainbow" jest po prostu szczególnym rodzajem tabeli wyszukiwania, która umożliwia określony rodzaj kompresji danych na kluczach. Poprzez obrót obliczeń dla przestrzeni, tabela wyszukiwania, która zajęłaby 1000 TB, może być skompresowana tysiąc razy, dzięki czemu może być przechowywana na mniejszym dysku.

Powinieneś się martwić hash do tabel wyszukiwania haseł, rainbow lub inaczej.

@onebyone.livejournal.com:

Atakujący ma 'tęczowe tabele' składające się nie z hashów słów słownikowych, ale ze stanu obliczeń hash tuż przed zakończeniem obliczeń hash.

Byłoby wtedy tańsze wymuszenie wpisania pliku hasła z Postfix salt niż przedrostek salt: dla każdego słowa słownikowego z kolei można załadować stan, dodać bajty salt do hasha, a następnie zakończyć go. Z prefiksem soli będzie nie ma nic wspólnego między obliczeniami dla każdego słowa słownikowego.

Dla prostej funkcji skrótu, która skanuje liniowo przez ciąg wejściowy, takiej jak prosty generator liniowy, jest to atak praktyczny. Ale kryptograficznie bezpieczna funkcja hash jest celowo zaprojektowana tak, aby miała wiele rund, z których każda wykorzystuje wszystkie bity ciągu wejściowego, tak że obliczanie stanu wewnętrznego tuż przed do dodania soli nie ma sensu po pierwsza runda. Na przykład SHA-1 mA 80 pocisków.

Ponadto algorytmy hashujące hasła, takie jak PBKDF, składają swoją funkcję hashową wiele razy (zaleca się iterację pbkdf-2 minimum 1000 razy, przy czym każda iteracja stosuje SHA-1 dwa razy) czyniąc ten atak podwójnie niepraktycznym.

BCrypt hash jeśli platforma ma dostawcę. Uwielbiam, jak nie martw się o tworzenie soli i możesz je jeszcze silniejsze, jeśli chcesz.

Wstawianie soli dowolnej liczby znaków do hasła jest najmniej oczekiwanym przypadkiem, a zatem najbardziej" bezpiecznym " społecznie, ale tak naprawdę nie jest to bardzo istotne w ogólnym przypadku, o ile używasz długich, unikalnych ciągów dla soli.