Konieczność ukrycia soli do haszyszu

99

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

security encryption hash brute-force kemiller2002
źródło
Dobre pytanie, Kevin, bardzo na czasie. Nie mogę komentować bezpieczeństwa, ale na pewno jest to hit wydajnościowy w całym tym szyfrowaniu i odszyfrowywaniu.
DOK
Nie musisz ignorować tęczowego stołu o przyzwoitym rozmiarze - ten stół również sprawia, że ​​zaszyfrowana sól działa, ponieważ może odszyfrować solony hash i może zostać ponownie użyty do odszyfrowania oryginalnego skrótu. Dobra wiadomość jest taka, że ​​stworzenie stołu zajęłoby prawdopodobnie wieki.
tloach
Dotyka mnie to, że nie jestem do końca pewien, czy stworzenie tęczowego stołu o takich rozmiarach zajmie tyle czasu. To zwariowany pomysł, weź rozproszoną platformę obliczeniową, taką jak Kraken (tak naprawdę to jest), aby go wygenerować. Jak długo to zajmie?
kemiller2002
3
@Kevin: SHA1 zwraca 40-znakowy ciąg szesnastkowy, więc istnieje 40 ^ 16 możliwych wartości zwracanych. Zakładając, że pojedynczy komputer może obliczyć 1000 hashów na sekundę, obliczam, że 1 000 000 komputerów zajęłoby około 10 miliardów lat, aby wygenerować tęczową tablicę zdolną określić ciąg o takiej wielkości.
tloach
+1 dobre pytanie i jesteś dobrze przeczytany. Myślę, że źle odpowiedziałeś na to pytanie. To zawsze powinno być tajemnicą, ponieważ hasha nie można złamać, dopóki nie zostanie uzyskany. Powinieneś przeczytać o CWE-760 ( cwe.mitre.org/data/definitions/760.html )
wieża

Odpowiedzi:

45

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.

tloach
źródło
Trochę nowy w tych koncepcjach. Może to wyglądać na naiwne pytanie, ale czy nie byłoby łatwiej utworzyć tęczową tabelę ze znajomością soli dla każdego hasła, ponieważ wypróbowałbyś tylko jedną kombinację wartości soli dla każdego możliwego hasła?
wyjście
tablica ranbow z, powiedzmy, 1000 powszechnie używanych haseł złamałaby to z prawie taką samą prędkością, jak samo haszowanie. Jedynym sposobem, by to zadziałało, jest to, że jeśli
założysz
100

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.

erickson
źródło
1
Ukrywanie soli jest konieczne, ponieważ haszyszu nie można rozbić, dopóki nie zostanie uzyskany. Jest to związane z CWE-760 ( cwe.mitre.org/data/definitions/760.html )
wieża
28
@The Rook - Nie, źle interpretujesz ten problem. Odnosi się do stosowania przewidywalnych soli. Nie mówi nic o utrzymywaniu tajemnicy soli. Rzeczywiście, nie możesz naprawdę zachować sekretu soli bez użycia innego sekretu ... w takim razie dlaczego nie użyłbyś drugiego sekretu jako soli? Używanie nazwy użytkownika jako soli jest złe, ponieważ jest prawdopodobne, że wiele systemów ma tę samą nazwę użytkownika, co sprawia, że ​​bardziej opłacalne jest zbudowanie tabeli dla tej konkretnej soli. Najlepsze są przypadkowe sole, ale nie trzeba ich trzymać w tajemnicy.
erickson
Zobacz też: stackoverflow.com/questions/1645161/…
Jacco
1
@erickson, myślę, że mylisz tutaj terminologię. Sole nie udaremniają ataków słownikowych, chyba że są ukryte. Wiele soli jest otwartych. A jeśli znasz sól, twój atak słownikowy jest spowolniony tylko przez czas potrzebny do dodania soli do twojego słownika :) Sole zapobiegają przeglądaniu tabel Rainbow .... które są cholernie szybkie. Jeśli napastnik zna twoją sól, nie jesteś chroniony przed atakiem słownikowym. Jeśli napastnik nie zna twojej soli, jesteś chroniony przed atakiem słownikowym i musi użyć ataku brutalnej siły.
Ultratrunks
4
@Ultratrunks Tak, wyjaśniłem niektóre z moich odpowiedzi na ten temat, używając terminu „wstępnie obliczone ataki słownikowe”. Bardziej ogólnie niż tabele Rainbow, odnosi się do dowolnej struktury, która umożliwia odwrotne wyszukiwanie tekstu jawnego przy użyciu jego skrótu jako klucza. Niezależnie od wybranych terminów, wyjaśniam wyraźnie, że sól ma na celu pokonanie tabel Rainbow i podobnych mechanizmów. Zawsze powinieneś zakładać, że napastnik zna sól. Gdyby można było zachować to w tajemnicy, nie musiałbyś haszować hasła.
erickson
3

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.

gbarry
źródło
3

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.

Bill the Lizard
źródło
Jak chronią przed atakami słownikowymi?
tloach
Zmuszając atakującego do stworzenia nowego słownika dla każdej kombinacji hasła i soli. Bez soli jeden słownik może być użyty przeciwko całej tabeli haseł.
Bill the Lizard
„Oczywiście kwestia jest dyskusyjna, czy atakujący uzyska całą Twoją bazę danych, sole i wszystko”. Czy nie dlatego sól jest zaszyfrowana?
Patrick McElhaney,
1
@Bill: Właśnie opisałeś tęczowy stół. Atak słownikowy polega na tym, że biorę zwykłe słowa i próbuję się nimi uwierzytelnić. To brutalna siła ze znacznie zmniejszoną przestrzenią odpowiedzi. Żaden hash nie chroni przed brutalną siłą.
tloach
Nigdy nie słyszałem o tej praktyce, ale nie jestem ekspertem ds. Bezpieczeństwa. Wygląda na to, że szyfrowanie unikalnych soli zapewniłoby dodatkową warstwę ochrony przed atakami tęczowej tablicy.
Bill the Lizard
3

... 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?

Zaraz
źródło
2
Nie wspominając o tym, że używasz arbitralnych informacji o użytkowniku, kiedy zmieniają te informacje, musisz ponownie wprowadzić hasło, abyś mógł je ponownie zaszyfrować za pomocą nowej soli.
Treborbob
3

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 .

John Wu
źródło
2

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.

Charles Faiga
źródło
Nie używamy tego samego skrótu dla każdego konta, używamy tego samego typu informacji dla każdego skrótu. Na przykład sól do konta to numer
telefonu
Wiem, że minęło dużo czasu, ale ... nie możesz polegać na solach, aby ochronić się przed tego typu atakiem. Musimy założyć, że atakujący wie wszystko o systemie uwierzytelniania poza sekretem (tj. Hasłem). Dlatego musimy założyć, że atakujący wie a) czego używamy jako soli (najczęściej jest to przechowywane w tej samej bazie danych i tabeli w postaci zwykłego tekstu) oraz b) w jaki sposób haszujemy z solą (tj. Dołączamy, haszujemy dwa razy, itp). Jeśli użytkownik ma możliwość przełączania skrótów, musimy założyć, że może również przełączać sól. Sole tu nie pomogą.
Dave Satch
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.

Javier
źródło
0

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.

Russell Hankins
źródło
Więc jeśli moje hasło to „345678”, a przypadkowo wpisana sól to, powiedzmy, „12”. Jeśli ktoś wpisze „45678” jako moje hasło. Wydaje się to błędne z wielu powodów.
Yurippenet
-1

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ą?

Lucas Oman
źródło
2
Gdyby ktoś brutalnie wymusił tak niemożliwe do odgadnięcia hasło, powiedziałbym, że i tak zostałeś spętany, ponieważ najwyraźniej mają technologię, o której nikt nawet nie pomyślał.
Instance Hunter