Konieczność ukrycia soli do haszyszu

W pracy mamy dwie konkurencyjne teorie dotyczące soli. Produkty, nad którymi pracuję, używają czegoś takiego jak nazwa użytkownika lub numer telefonu, aby posolić hash. Zasadniczo coś, co jest różne dla każdego użytkownika, ale jest dla nas łatwo dostępne. Drugi produkt losowo generuje sól dla każdego użytkownika i zmienia się za każdym razem, gdy użytkownik zmienia hasło. Sól jest następnie szyfrowana w bazie danych.

Moje pytanie brzmi, czy drugie podejście jest naprawdę konieczne? Rozumiem z czysto teoretycznej perspektywy, że jest to bezpieczniejsze niż pierwsze podejście, ale z praktycznego punktu widzenia. W tej chwili, aby uwierzytelnić użytkownika, sól musi być niezaszyfrowana i zastosowana do informacji logowania.

Po przemyśleniu tego po prostu nie widzę rzeczywistego zwiększenia bezpieczeństwa w wyniku takiego podejścia. Zmiana typu „sól” z konta na konto nadal bardzo utrudnia komuś próbę brutalnego wymuszenia algorytmu mieszającego, nawet jeśli osoba atakująca była świadoma, jak szybko określić, co to było dla każdego konta. Odbywa się to przy założeniu, że hasła są wystarczająco silne. (Oczywiście znalezienie poprawnego skrótu dla zestawu haseł, w którym wszystkie mają dwie cyfry, jest znacznie łatwiejsze niż znalezienie prawidłowego skrótu haseł składających się z 8 cyfr). Czy moja logika jest niepoprawna, czy jest coś, czego mi brakuje?

EDYCJA: OK, więc oto powód, dla którego myślę, że szyfrowanie soli jest naprawdę dyskusyjne. (daj mi znać, czy jestem na dobrej drodze).

W poniższym wyjaśnieniu zakładamy, że hasła mają zawsze 8 znaków, a sól to 5, a wszystkie hasła składają się z małych liter (to po prostu ułatwia obliczenia).

Posiadanie innej soli dla każdego wpisu oznacza, że ​​nie mogę używać tego samego stołu tęczowego (właściwie technicznie bym mógł, gdybym miał jeden o wystarczającej wielkości, ale na razie zignorujmy to). To jest prawdziwy klucz do soli z tego, co rozumiem, ponieważ aby złamać każde konto, muszę wymyślić koło na nowo dla każdego. Teraz, jeśli wiem, jak zastosować poprawną sól do hasła, aby wygenerować hash, zrobiłbym to, ponieważ sól tak naprawdę zwiększa długość / złożoność zahaszowanej frazy. Więc ograniczyłbym liczbę możliwych kombinacji, które musiałbym wygenerować, aby "wiedzieć" Mam hasło + sól z 13 ^ 26 do 8 ^ 26, ponieważ wiem, co to jest sól. Teraz jest to łatwiejsze, ale nadal bardzo trudne.

A więc do zaszyfrowania soli. Gdybym wiedział, że sól jest zaszyfrowana, nie próbowałbym jej najpierw odszyfrować (zakładając, że wiem, że ma wystarczający poziom szyfrowania). Zignorowałbym to. Zamiast zastanawiać się, jak to odszyfrować, wracając do poprzedniego przykładu, wygenerowałbym po prostu większą tęczową tabelę zawierającą wszystkie klucze dla 13 ^ 26. Brak znajomości soli na pewno by mnie spowolnił, ale nie sądzę, że dodałoby to monumentalne zadanie polegające na próbie złamania najpierw szyfrowania soli. Dlatego uważam, że nie warto. Myśli?

Oto link opisujący, jak długo hasła będą przechowywane podczas ataku siłowego: http://www.lockdown.co.uk/?pg=combi

Odpowiedź brzmi: zadaj sobie pytanie, przed czym naprawdę próbujesz się chronić? Jeśli ktoś ma dostęp do Twojej bazy danych, to ma dostęp do zaszyfrowanych soli i prawdopodobnie ma również dostęp do Twojego kodu. Z tym wszystkim mogliby odszyfrować zaszyfrowane sole? Jeśli tak, to i tak szyfrowanie jest prawie bezużyteczne. Sól naprawdę jest po to, aby to zrobić, więc nie można utworzyć tęczowej tabeli, aby złamać całą bazę danych haseł za jednym razem, jeśli zostanie włamana. Z tego punktu widzenia, o ile każda sól jest unikalna, nie ma żadnej różnicy, wymagany byłby atak brutalnej siły przy użyciu twoich soli lub zaszyfrowanych soli dla każdego hasła z osobna.

Ukrywanie soli nie jest konieczne.

Do każdego haszyszu należy użyć innej soli. W praktyce jest to łatwe do osiągnięcia, uzyskując 8 lub więcej bajtów z generatora liczb losowych o jakości kryptograficznej.

Z mojej poprzedniej odpowiedzi :

Sól pomaga udaremnić wstępnie obliczone ataki słownikowe.

Załóżmy, że osoba atakująca ma listę prawdopodobnych haseł. Może je zaszyfrować i porównać z hasłem swojej ofiary i sprawdzić, czy pasuje. Jeśli lista jest obszerna, może to zająć dużo czasu. Nie chce spędzać tyle czasu na swoim następnym celu, więc zapisuje wynik w „słowniku”, w którym hash wskazuje na odpowiadający mu wpis. Jeśli lista haseł jest bardzo, bardzo długa, może użyć technik takich jak Rainbow Table, aby zaoszczędzić trochę miejsca.

Jednak przypuśćmy, że jego następny cel zasolił ich hasło. Nawet jeśli atakujący wie, czym jest sól, jego wstępnie obliczona tabela jest bezwartościowa - sól zmienia wartość skrótu wynikającą z każdego hasła. Musi ponownie zhashować wszystkie hasła ze swojej listy, dołączając sól celu do wejścia. Każda inna sól wymaga innego słownika, a jeśli zostanie użyta wystarczająca ilość soli, napastnik nie będzie miał miejsca na przechowywanie ich wszystkich słowników. Wymiana przestrzeni w celu zaoszczędzenia czasu nie jest już opcją; atakujący musi wrócić do haszowania każdego hasła ze swojej listy dla każdego celu, który chce zaatakować.

Więc nie jest konieczne trzymanie soli w tajemnicy. Wystarczy upewnić się, że atakujący nie ma wstępnie obliczonego słownika odpowiadającego tej konkretnej soli.

Po dłuższym przemyśleniu zdałem sobie sprawę, że oszukiwanie się w myśleniu, że sól można ukryć, jest niebezpieczne. O wiele lepiej jest założyć, że soli nie da się ukryć i mimo to zaprojektować system tak, aby był bezpieczny. Bardziej szczegółowe wyjaśnienie podam w innej odpowiedzi.

Jednak ostatnie zalecenia NIST-u zachęcają do stosowania dodatkowej, sekretnej „soli” (widziałem, jak inni nazywają tę dodatkową tajemnicę „pieprzem”). Można wykonać jedną dodatkową iterację wyprowadzenia klucza, używając tego sekretu jako soli. Zamiast zwiększać siłę przed wstępnie obliczonym atakiem wyszukiwania, ta runda chroni przed zgadywaniem hasła, podobnie jak duża liczba iteracji w dobrej funkcji wyprowadzania klucza. Ten sekret nie ma sensu, jeśli jest przechowywany z zaszyfrowanym hasłem; musi być zarządzany jako tajemnica, a to może być trudne w przypadku dużej bazy danych użytkowników.

Moje rozumienie pojęcia „sól” jest takie, że utrudnia pękanie, ale nie próbuje ukryć dodatkowych danych. Jeśli próbujesz uzyskać większe bezpieczeństwo, czyniąc sól „sekretną”, tak naprawdę potrzebujesz więcej bitów w swoich kluczach szyfrowania.

Drugie podejście jest tylko trochę bezpieczniejsze. Sole chronią użytkowników przed atakami słownikowymi i atakami tęczowej tablicy. Utrudniają ambitnemu napastnikowi złamanie zabezpieczeń całego systemu, ale nadal są podatne na ataki skoncentrowane na jednym użytkowniku systemu. Jeśli korzystasz z publicznie dostępnych informacji, takich jak numer telefonu, a napastnik zdaje sobie z tego sprawę , oszczędzasz mu kroku w ataku. Oczywiście pytanie jest dyskusyjne, czy atakujący uzyska całą twoją bazę danych, sole i wszystko.

EDYCJA: Po ponownym przeczytaniu tej odpowiedzi i niektórych komentarzy, wydaje mi się, że część nieporozumień może wynikać z faktu, że porównuję tylko dwa bardzo specyficzne przypadki przedstawione w pytaniu: przypadkowa sól vs. nieprzypadkowa sól. Kwestia wykorzystania numeru telefonu jako soli jest dyskusyjna, jeśli atakujący uzyska całą twoją bazę danych, a nie kwestia użycia soli w ogóle.

... coś w rodzaju nazwy użytkownika lub numeru telefonu, aby doprawić hash. ...

Moje pytanie brzmi, czy drugie podejście jest naprawdę konieczne? Rozumiem z czysto teoretycznej perspektywy, że jest to bezpieczniejsze niż pierwsze podejście, ale co z praktycznego punktu widzenia?

Z praktycznego punktu widzenia sól jest szczegółem wykonania. Jeśli kiedykolwiek zmienisz sposób gromadzenia lub przechowywania informacji o użytkowniku - a czasami zmieniają się zarówno nazwy użytkowników, jak i numery telefonów, aby użyć dokładnych przykładów - być może naruszyłeś swoje bezpieczeństwo. Czy chcesz, aby taka zmiana skierowana na zewnątrz miała znacznie głębsze obawy dotyczące bezpieczeństwa?

Czy rezygnacja z wymogu posiadania numeru telefonu na każdym koncie wymaga pełnego przeglądu bezpieczeństwa, aby upewnić się, że nie otworzyłeś tych kont ze względu na zagrożenie bezpieczeństwa?

Ukryta sól nie jest już solą. To pieprz. Ma swoje zastosowanie. Różni się od soli.

Pepper to tajny klucz dodawany do hasła i soli, który zamienia skrót w HMAC (Hash Based Message Authentication Code). Haker z dostępem do danych wyjściowych skrótu i ​​soli może teoretycznie brutalnie odgadnąć dane wejściowe, które wygenerują skrót (i tym samym przejdą weryfikację w polu tekstowym hasła). Dodając pieprz, zwiększasz przestrzeń problemową w kryptograficznie losowy sposób, czyniąc problem niemożliwym do rozwiązania bez poważnego sprzętu.

Więcej informacji na temat pieprzu znajdziesz tutaj .

Zobacz też hmac .

Oto prosty przykład pokazujący, dlaczego źle jest mieć taką samą sól dla każdego haszyszu

Rozważ poniższą tabelę

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

Przypadek 1, gdy sól 1 jest tym samym, co sól2 Jeśli Hash2 zostanie zastąpiony hasłem Hash1, użytkownik 2 może zalogować się przy użyciu hasła użytkownika 1

Przypadek 2, gdy sól 1 to nie to samo salt2 Jeśli Hash2 zostanie zastąpione hasłem Hash1, użytkownik2 nie może zalogować się przy użyciu hasła użytkownika 1.

Istnieją dwie techniki o różnych celach:

• „Sól” służy do szyfrowania dwóch równych sobie haseł w inny sposób. W ten sposób intruz nie może efektywnie wykorzystać ataku słownikowego na całą listę zaszyfrowanych haseł.

• (Udostępniony) „sekret” jest dodawany przed zahaszowaniem wiadomości, aby intruz nie mógł tworzyć własnych wiadomości i wymagać ich akceptacji.

Mam tendencję do ukrywania soli. Używam 10 bitów soli, dodając losową liczbę od 1 do 1024 na początku hasła przed jego zahaszowaniem. Porównując hasło wprowadzone przez użytkownika z hashem, zapętlam od 1 do 1024 i sprawdzam każdą możliwą wartość soli, aż znajdę dopasowanie. Zajmuje to mniej niż 1/10 sekundy. Wpadłem na pomysł, aby to zrobić w ten sposób z PHP password_hash i password_verify . W moim przykładzie „koszt” to 10 za 10 bitów soli. Albo, jak powiedział inny użytkownik, ukryta „sól” nazywa się „pieprzem”. Sól nie jest zaszyfrowana w bazie danych. To brutalne wymuszenie. To sprawiłoby, że tęczowa tabela musiałaby odwrócić hasz 1000 razy większy. Używam sha256, ponieważ jest szybki, ale nadal uważany za bezpieczny.

Tak naprawdę zależy to od rodzaju ataku, który próbujesz chronić swoje dane.

Celem unikalnej soli dla każdego hasła jest zapobieganie atakowi słownikowemu na całą bazę danych haseł.

Szyfrowanie unikalnej soli dla każdego hasła utrudniłoby złamanie indywidualnego hasła, tak, ale musisz rozważyć, czy jest to naprawdę duża korzyść. Jeśli atakujący brutalną siłą stwierdzi, że ten ciąg:

Marianne2ae85fb5d

hashami do hasha przechowywanego w DB, czy naprawdę trudno jest dowiedzieć się, która część jest przepustką, a która solą?