Gdzie przechowujesz struny solne?

podam nieco inne podejście do tej sprawy.

Zawsze przechowuję sól zmieszaną z Hashem solonego hasła.

Na przykład pierwszą połowę soli umieszczę przed solonym-hash hasła, a ostatnią połowę soli po solonym-hash hasła. Aplikacja jest świadoma tego projektu, więc może pobrać te dane i uzyskać hash salt i salted-password.

Moje uzasadnienie takiego podejścia:

Jeśli hasło / hash dane są zagrożone i wpada w ręce atakującego, atakujący nie będzie wiedział, co sól jest patrząc na dane. W ten sposób atakujący nie może praktycznie wykonać ataku brute-force, aby uzyskać hasło pasujące do hasha, ponieważ nie zna go na początku i nie ma możliwości poznania, które części danych są częściami salt lub częściami hash hasła Solar(chyba że zna uwierzytelnienie Twojej aplikacji logika).

Jeśli hash solone-password jest przechowywany jako-is, to atak brute-force może zostać wykonany w celu uzyskania hasła, które w przypadku salted i hashed generuje te same dane, co hash solone-password.

Jednak, na przykład, nawet jeśli hash solone-password został zapisany jako-is, ale wstępnie zsynchronizowany z pojedynczym losowym bajtem, tak długo, jak atakujący nie jest świadomy, że ten pierwszy bajt ma zostać odrzucony, zwiększyłoby to również trudność ataku. Twoja aplikacja będzie wiedzieć, aby odrzucić pierwszy bajt danych, gdy jest używany do uwierzytelnienia użytkownika.

Wniosek z tego..

1) Nigdy nie przechowuj danych używanych przez Twoją aplikację uwierzytelniającą w jej dokładnej formie.

2) jeśli to możliwe, zachowaj logikę uwierzytelniania w tajemnicy dla dodatkowego bezpieczeństwa.

Idź o krok dalej..

Jeśli nie możesz utrzymać logiki uwierzytelniania aplikacji w tajemnicy - Wiele osób wie, w jaki sposób Twoje dane są przechowywane w bazie danych. Oraz Załóżmy, że zdecydowałeś się przechowywać hash solone-password zmieszany z solą, z częścią soli poprzedzającą hash solone-password, a resztą soli dołączającą go.

Podczas generowania losowej soli, możesz również losowo zdecydować, jaka część soli będzie przechowywana przed / po hashowaniu hasła solonego.

Na przykład, generujesz losową sól o wielkości 512 bajtów. Dołączasz sól do swojego hasła i uzyskujesz hash SHA-512 swojego solone-hasło. Generujesz również losową liczbę całkowitą 200. Następnie zapisuje się pierwsze 200 bajtów salt, a następnie hash Solent-password, a następnie resztę salt.

Podczas uwierzytelniania hasła użytkownika, aplikacja przekaże ciąg znaków i załóżmy, że pierwszy 1 bajt danych jest pierwszym 1 bajtem salt, a następnie Solent-hash. Ta przepustka zawiedzie. Aplikacja będzie kontynuowana, używając pierwszych 2 bajtów danych jako pierwszych 2 bajtów sól i powtarzaj do momentu znalezienia pozytywnego wyniku po użyciu pierwszych 200 bajtów jako pierwszych 200 bajtów soli. Jeśli hasło jest błędne, aplikacja będzie nadal próbować wszystkich permutacji, dopóki nie zostaną znalezione żadne.

zalety tego podejścia:

Zwiększone bezpieczeństwo - nawet jeśli logika uwierzytelniania jest znana, dokładna logika nie jest znana podczas kompilacji. Jest to praktycznie niemożliwe do wykonania ataku brute-force, nawet ze znajomością dokładnej logiki. Zwiększona długość soli zwiększy bezpieczeństwo.

wady takiego podejścia:

Ponieważ dokładna logika jest wnioskowana w czasie wykonywania, podejście to jest bardzo obciążające CPU. Im dłuższa jest długość soli, tym bardziej intensywne staje się to podejście.

Uwierzytelnianie nieprawidłowych haseł wiąże się z najwyższymi kosztami procesora. Może to być niekorzystne dla uzasadnionych wniosków, ale zwiększa bezpieczeństwo przed atakującymi.

Takie podejście może być zaimplementowane na różne sposoby i mogą być jeszcze bardziej bezpieczne dzięki użyciu soli o zmiennej szerokości i / lub hashów hasła solowego.

Często są one dołączane do hasha i przechowywane w tym samym polu.

Nie ma potrzeby przechowywania ich osobno - chodzi o to, aby użyć losowej soli dla każdego hasła, aby pojedyncza tęczowa tabela nie mogła być używana przeciwko całemu zestawowi skrótów haseł. W przypadku soli losowych atakujący musi wymusić każdy hash osobno (lub obliczyć tęczową tabelę dla wszystkich możliwych soli-znacznie więcej pracy).

Jeśli masz bardziej bezpieczne miejsce przechowywania, byłoby sensowne, aby po prostu przechowuj tam hasze.

Na podstawie opracowania ASP.NET MVC 4 Web Applications book by William Penberthy:

1. uzyskanie dostępu do soli przechowywanych w oddzielnej bazie danych wymaga od hakerów włamania dwóch różne bazy danych, aby uzyskać dostęp do salt i hasła solone. Przechowywanie ich w tej samej tabeli co hasło, a nawet innej tabeli tej samej bazy danych, oznacza, że gdy hakerzy uzyskają dostęp do bazy danych, będą mieli dostęp zarówno do sól i hash hasła. Ponieważ bezpieczeństwo obejmuje proces tworzenia hackingu do systemu zbyt kosztownego lub czasochłonnego, aby było warto, podwajając kwotę dostępu haker musiałby uzyskać powinien uczynić system bezpieczniejszym.
2. łatwość użycia jest głównym powodem przechowywania soli w tej samej bazie danych, co zaszyfrowane hasła. Nie musisz mieć pewności, że dwie bazy danych są zawsze dostępne w tym samym czasie i zawsze w synchronizacji. Zaleta posiadania soli jest minimalna, jeśli każdy użytkownik ma randomizowaną sól, ponieważ chociaż może to sprawić, że odkrycie jednostki hasło łatwiejsze, ilość siły niezbędnej do złamania haseł z system ogólnie będzie wysoki. Na tym poziomie dyskusji, to jest naprawdę to, co oczekiwanie jest: w celu ochrony haseł. Jeśli hakerzy nabyli kopię bazy danych, twój dane aplikacji są już zagrożone. W tym momencie problem polega na złagodzeniu użytkowników" zagrożenia ze względu na potencjał współdzielonych haseł.
3. wymóg utrzymywania dwóch oddzielne połączone, bazy danych są obszerne. / Align = "left" / dodaje postrzeganie bezpieczeństwa, ale jedyną zaletą, jaką daje, jest to, że chroni hasło, pojedynczy element danych. Jeśli każde pole w bazie danych było indywidualnie zaszyfrowane, a do tego użyto tej samej soli, bardziej sensowne byłoby jej przechowywanie oddzielnie od danych, ponieważ zwiększa się podstawowe bezpieczeństwo systemu.