Podam nieco inny wniosek w tej sprawie.
Zawsze przechowuję sól wymieszaną z hashem z solonym hasłem.
Na przykład, umieszczę pierwszą połowę soli przed solonym hashem hasła, a ostatnią połowę soli po solonym haszem hasła. Aplikacja jest świadoma tego projektu, więc może pobrać te dane, i uzyskać hash soli i solonego hasła.
Moja Uzasadnieniem takiego podejścia:
Jeśli dane hasło/hash jest zagrożona i wpada w ręce atakującego, atakujący nie będzie wiedział, co sól jest od patrzenia na dane. W ten sposób atakujący nie może praktycznie wykonać brutalnego ataku, aby uzyskać hasło pasujące do hasza, ponieważ nie zna on hasha, od którego zaczyna się i nie ma możliwości dowiedzenia się, które części danych są częściami soli, lub części hasha z hasłem solonym (, chyba że zna logikę uwierzytelniania twojej aplikacji).
Jeśli hash z hasłem solonym jest przechowywane tak jak jest, można wykonać atak brute-force, aby uzyskać hasło, które po zasoleniu i mieszaniu generuje te same dane, co hash z hasłem solonym.
Jednak, na przykład, nawet jeśli asocjacja z hasłem solonym była przechowywana tak jak jest, lecz wstępnie zawierała pojedynczy losowy bajt, o ile atakujący nie jest świadomy, że ten pierwszy bajt ma zostać odrzucony, również zwiększyć trudność ataku. Twoja aplikacja będzie wiedziała, że odrzuca pierwszy bajt danych, gdy jest używany do uwierzytelnienia użytkownika.
Zawarcie tego ..
1) Nie wolno przechowywać dane, że aplikacja używa uwierzytelniania w to dokładna forma.
2) Jeśli to możliwe, utrzymuj logikę uwierzytelniania w tajemnicy, aby zwiększyć bezpieczeństwo.
pójść o krok dalej ..
Jeśli nie można zachować logikę uwierzytelniania tajemnicę swojej aplikacji - wiele osób wie, w jaki sposób dane są przechowywane w bazie danych. I przypuśćmy, że zdecydowałeś się przechowywać mieszany hash z domieszką soli razem z solą, z częścią soli poprzedzającą hash z solonym hasłem i resztą soli, która się do niego dołącza.
Podczas generowania losowej soli, możesz również losowo zdecydować, jaka część twojej soli będzie przechowywana przed/po hashowaniu solonym hasłem.
Na przykład generowana jest losowa sól o wielkości 512 bajtów. Dodajesz sól do swojego hasła i otrzymujesz skrót SHA-512 swojego solonego hasła. Generujesz losową liczbę całkowitą 200. Następnie przechowujesz pierwsze 200 bajtów soli, następnie hash solonego hasła, a następnie resztę soli.
Podczas uwierzytelniania hasła wprowadzanego przez użytkownika, aplikacja przejdzie przez ciąg znaków i przyjmie, że pierwszy 1 bajt danych jest pierwszym 1 bajtem soli, a następnie solonym hashem. Ta przepustka nie powiedzie się. Aplikacja będzie kontynuowana przez użycie pierwszych 2 bajtów danych jako pierwszych 2 bajtów soli i powtórzyć, aż wynik dodatni zostanie znaleziony po użyciu pierwszych 200 bajtów jako pierwszych 200 bajtów soli. Jeśli hasło jest nieprawidłowe, aplikacja będzie nadal próbowała wszystkich permutacji, dopóki nie zostaną znalezione żadne.
Zalety tego rozwiązania:
Zwiększone bezpieczeństwo - nawet jeśli logika uwierzytelniania jest znana dokładna logika nie jest znany w czasie kompilacji. Próba brutalnej siły jest praktycznie niemożliwa, nawet przy znajomości dokładnej logiki. Zwiększona ilość soli zwiększy bezpieczeństwo.
Wady tego podejścia:
Ponieważ dokładna logika jest wywnioskować w czasie wykonywania, takie podejście jest bardzo intensywnie CPU. Im dłuższa długość soli, tym podejście staje się bardziej obciążające procesor.
Uwierzytelnianie nieprawidłowych haseł wiąże się z najwyższymi kosztami procesora. Może to przynieść efekt odwrotny do uzasadnionych żądań, ale zwiększa bezpieczeństwo przed atakującymi.
To podejście może być realizowane na różne sposoby i może być jeszcze bardziej bezpieczne dzięki zastosowaniu soli o zmiennej szerokości i/lub skrótów z hasłami solennymi.
Jeśli istnieje miejsce, w którym można przechowywać sól, do której atakujący nie może się dostać, wówczas należy po prostu przechowywać tam również hasła. Ale dlaczego nie użyć innej soli dla każdego hasła? – jrockway
Używa innej soli dla każdego hasła, jrockway. – Amber
Jak duże są twoje sole? Twoje sole powinny być wystarczająco duże (32 bity?), Że praktycznie nie ma szansy, że stół tęczowy został wstępnie obrobiony. –