Zwykle działa to tak:

Powiedz, że Twoje hasło to „baseball”. Mógłbym po prostu przechowywać to w stanie surowym, ale każdy, kto zdobędzie moją bazę danych, otrzyma hasło. Więc zamiast tego robię na nim hash SHA1 i otrzymuję to:

  $ echo -n baseball | sha1suma2c901c8c6dea98958c219f6f2d038c44dc5d362  

Teoretycznie niemożliwe jest odwrócenie skrótu SHA1. Ale idź wyszukaj w Google dokładnie ten ciąg, a nie będziesz mieć problemu z odzyskaniem oryginalnego hasła.

Ponadto, jeśli dwóch użytkowników w bazie danych ma to samo hasło, to będą mieć ten sam skrót SHA1. A jeśli jeden z nich ma wskazówkę do hasła, która mówi spróbuj „baseball” - cóż, teraz wiem, czym są oba hasła użytkowników.

Więc zanim go zhaszujemy, dołączamy unikalny ciąg. To nie jest sekret , po prostu coś wyjątkowego. A co z WquZ012C . Więc teraz haszujemy ciąg WquZ012Cbaseball . To oznacza to:

c5e635ec235a51e89f6ed7d4857afe58663d54f5

Przeszukanie w Google tego ciągu nic nie daje (z wyjątkiem być może tego strona), więc teraz coś jest. A jeśli person2 również używa „baseball” jako swojego hasła, używamy innej soli i otrzymujemy inny hash.

Oczywiście, aby przetestować swoje hasło, musisz wiedzieć, co to za sól. Więc musimy to gdzieś przechowywać. Większość implementacji po prostu umieszcza to w tym miejscu za pomocą skrótu, zwykle z pewnym ogranicznikiem. Spróbuj tego, jeśli masz zainstalowane openssl :

  [tylerl ~] $ openssl passwd -1Password: baseballVerifying - Password: baseball $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0  

To daje nam hash przy użyciu standardowej biblioteki crypt . Więc nasz skrót to $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0 : to w rzeczywistości 3 sekcje oddzielone $ . Zastąpię separator spacją, aby był bardziej przejrzysty:

  $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0 1 oaagVya9 NMvf1IyubxEYvrZTRSLgk0

• 1 oznacza „algorytm numer 1”, który jest trochę skomplikowany, ale używa MD5. Istnieje wiele innych, które są znacznie lepsze, ale to jest nasz przykład.
• oaagVya9 to nasza sól. Umieszczony tam z naszym hashem.
• NMvf1IyubxEYvrZTRSLgk0 to rzeczywista suma MD5 zakodowana w base64.

Jeśli uruchomię proces znowu dostaję zupełnie inny haszysz z inną solą. W tym przykładzie istnieje około 10 ¹⁴ sposobów przechowywania tego jednego hasła. Wszystkie z nich dotyczą hasła „baseball”:

  $ 1 $ 9XsNo9.P $ kTPuyvrHqsJJuCci3zLwL. $ 1 $ nLEOCtx6 $ uSnz6PF8q3YuUhB3rLTC3 / ​​$ 1 $ / jZJXTF3 $ WfDukpe. U $ KR0jkhpeb1sz.UIqvfYOR.  

Ale jeśli celowo określę sól, którą chcę sprawdzić, odzyskam oczekiwany wynik:

  [ tylerl ~] $ openssl passwd -1 -salt oaagVya9Hasło: baseballVerifying - Hasło: baseball $ 1 $ oaagVya9 $ NMvf1IyubxEYvrZTRSLgk0  

I to jest test, który przeprowadzam, aby sprawdzić, czy hasło jest poprawne. Znajdź przechowywany hash dla użytkownika, znajdź zapisaną sól, ponownie uruchom ten sam hash używając zapisanej soli, sprawdź, czy wynik jest zgodny z oryginalnym hashem.

Implementing This Yourself

Żeby było jasne, ten post nie jest przewodnikiem po implementacji. Nie posolaj MD5 i nie nazywaj go dobrym. To za mało w dzisiejszym klimacie ryzyka. Zamiast tego będziesz chciał uruchomić iteracyjny proces, który uruchamia funkcję haszującą tysiące razy. Było to wyjaśniane w innym miejscu wiele razy, więc nie będę tutaj omawiać „dlaczego” .

Jest kilka dobrze ugruntowanych i zaufane możliwości zrobienia tego:

• crypt : Funkcja, której użyłem powyżej, jest starszą wersją mechanizmu haszowania haseł unix crypt wbudowanego we wszystkie Systemy operacyjne Unix / Linux. Oryginalna (oparta na DES) wersja jest strasznie niepewna; nawet o tym nie myśl. Ten, który pokazałem (oparty na MD5) jest lepszy, ale nadal nie powinien być używany. Późniejsze warianty, w tym warianty SHA-256 i SHA-512, powinny być rozsądne. Wszystkie najnowsze warianty implementują wiele rund haszów.

• bcrypt : Wersja Blowfish crypt kod> wezwanie funkcjonalne wspomniane powyżej. Wykorzystuje fakt, że Blowfish ma bardzo kosztowny proces konfiguracji klucza i przyjmuje parametr „koszt”, który odpowiednio wydłuża czas konfiguracji klucza.

• PBKDF2 : ("Funkcja wyprowadzania klucza opartego na haśle w wersji 2") Stworzona do tworzenia silnych kluczy kryptograficznych z prostych haseł, jest to jedyna wymieniona tutaj funkcja, która faktycznie ma RFC. Uruchamia konfigurowalną liczbę rund, a każda runda haszuje hasło i wynik poprzedniej rundy. Pierwsza runda używa soli. Warto zauważyć, że jego pierwotnym przeznaczeniem jest tworzenie silnych kluczy , a nie przechowywanie haseł , ale nakładanie się celów sprawia, że ​​jest to również godne zaufania rozwiązanie. Jeśli nie miałeś dostępnych bibliotek i byłeś zmuszony do implementacji czegoś od zera, jest to najłatwiejsza i najlepiej udokumentowana opcja. Chociaż, oczywiście, korzystanie z dobrze sprawdzonej biblioteki jest zawsze najlepsze.

• scrypt : niedawno wprowadzony system zaprojektowany szczególnie trudne do wdrożenia na dedykowanym sprzęcie. Oprócz wymagania wielu rund funkcji mieszającej, scrypt ma również bardzo duży stan pamięci roboczej, aby zwiększyć zapotrzebowanie na pamięć RAM dla implementacji. Chociaż jest bardzo nowy i w większości niesprawdzony, wygląda co najmniej tak samo bezpieczny jak inne i prawdopodobnie najbezpieczniejszy z nich wszystkich.

Technicznie rzecz biorąc, nadal możesz używać tęczowej tabeli do atakowania solonych haszów. Ale tylko technicznie. Solony haszysz pokonuje ataki tęczowego stołu, nie przez dodanie magii kryptograficznej, ale po prostu wykładniczo zwiększając rozmiar tęczowego stołu wymaganego do pomyślnego znalezienia kolizji.

I tak, musisz przechowywać sól :)

Nie jest dodawany po krzyżyku. Jest dodawany przed hashem, więc hash jest zupełnie inny dla każdej soli.

To nie jest

  hash abcd = defgstore 123defg (dla użytkownika z 123 salt) i 456defg (dla użytkownika z solą 456) 

Jest to

  hash 123abcd = ghij hash 456abcd = klmn  

W przypadku skrótów haseł musisz użyć czegoś takiego jak PBKDF2 / RFC2898 / PKCS5v2, Bcrypt lub Scrypt, z których wszystkie pozwalają wybrać liczbę iteracji („współczynnik pracy”), a nie niż tylko jeden. Na przykład PBKDF2 używa haszowania z kluczem HMAC z dobrze znanym algorytmem wyznaczania wartości skrótu (zwykle SHA-512, SHA-256 lub SHA-1) wewnętrznie dla wielu iteracji, najlepiej od dziesiątek do setek tysięcy tak wysoko, jak to tylko możliwe, zasadniczo bez narzekania użytkowników.

Przyczyną dużej liczby iteracji jest spowolnienie atakującego, co z kolei zmniejsza przestrzeń kluczową, przez którą może przejść w danym okresie , więc nie mogą skutecznie atakować lepszych haseł. Oczywiście „hasło” i „P @ $$ w0rd” zostaną złamane niezależnie od ataku offline.

Masz rację, każdy wiersz (użytkownik) potrzebuje własnej unikalnie wygenerowanej, kryptograficznie losowej długiej soli . Ta sól jest przechowywana w postaci tekstu jawnego.

W przypadku PBKDF2, Bcrypt lub Scrypt zalecałbym również przechowywanie liczby iteracji (współczynnika pracy) w bazie danych również w postaci zwykłego tekstu, aby można było łatwo zmienić (osobiście używam nieco losowej liczby iteracji - jeśli zawsze jest inaczej, jest mniej strachu, że „o nie, drobna zmiana może wszystko zepsuć - NIGDY NIE ZMIENIAJ TEGO PONOWNIE” od kierownictwa lub innych programistów)

Pamiętaj, że używając PBKDF2 jako hasła haszowanie, nigdy nie pytaj o większe dane wyjściowe niż natywne dane wyjściowe skrótu - dla SHA-1 to 20 bajtów, a dla SHA-512 to 64 bajty.

Aby podać rzeczywiste przykłady PBKDF2 z dwoma różnymi solami

(wyniki PBKDF2 HMAC Salt hasło iteracji outputbytes)

• PBKDF2 HMAC-SHA-512 mojehaslo vA8u3v4qzCdb 131072 64
  • 2e3259bece6992f012966cbf5803103fdea7957ac20f3ec305d62994a3f4f088f26cc3889053fb59a4e3c282f55e9179695609ee1147cffae1455880993ef874
• PBKDF2 HMAC-SHA-512 MyPass l6eZQVf7J65S 131072 64
  • 1018ad648096f7814bc2786972eb4091f6c36761a8262183c24b0f4d34abb48073ed2541ee273220915638b46ec14dfb2b23ad64c4aa12f97158340bdc12fc57

Oprócz tego, co powiedział Tylerl, ważne jest, aby podkreślić, że we współczesnych kryptowalutach sole nie są używane do ochrony przed tęczowymi tablicami. Nikt tak naprawdę nie używa tęczowych tabel. Prawdziwym niebezpieczeństwem jest zrównoleglenie:

• Jeśli nie masz soli lub tylko statycznej soli, a ja kradnę twój DB miliona hashów, mogę rzucić wszystkie moje rdzeni w bruteforsing it, a każdy rdzeń będzie atakował milion skrótów jednocześnie, ponieważ za każdym razem, gdy uderzę którykolwiek ciąg znaków używanych jako hasło, zobaczę dopasowanie skrótu. Dlatego muszę wyczerpać przestrzeń wyszukiwania raz , aby złamać milion haseł. Jest to całkowicie realistyczna skala wycieku haseł i wystarczająco atrakcyjny cel, aby rzucić kilka tuzinów GPU lub nawet niestandardowego FPGA. Nawet jeśli wyczerpię tylko dolne 30% przestrzeni wyszukiwania, i tak odejdę z 500 000 prawdziwych haseł. Te hasła zostaną następnie użyte do zbudowania mojego słownika, więc następnym razem, gdy ktoś wycieknie z bazy danych z hashami, złamie 90% z nich w ciągu kilku godzin.
• Jeśli zamiast tego każde hasło zostanie zaszyfrowane ze swoim własnym , unikalna sól, będę musiał zaatakować każdego z nich z osobna, ponieważ nawet identyczne hasła będą miały zupełnie inne skróty. Oznacza to, że być może mógłbym użyć mojej drogiej, energochłonnej farmy GPU / FPGA do zaatakowania kilku wartościowych celów (powiedzmy, że Obama byłby twoim użytkownikiem, to zdobycie jego hasła nadal gwarantowałoby wydatek), ale nie dostanę kilkaset tysięcy haseł za darmo. Gdybym chciał uzyskać całe miliony haseł, musiałbym przeprowadzić pełne wyszukiwanie siłowe milion razy.

I dlatego każda sól, statyczna lub nie, ochroni Cię przed przygotowanymi tęczowymi stołami, o ile nie jest szeroko stosowana, ale tylko unikalne sole haszyszowe ochronią Cię przed prawdziwym niebezpieczeństwem użycia dużej ilości równoległej mocy obliczeniowej do złamania wszystkiego. na raz.

Jest to bezpieczniejsze, ponieważ gdy wiele osób ma to samo hasło, będzie miało inny skrót.

Prosta implementacja za pomocą Pythona:

  import hashlibpasswordA = '123456'passwordB =' 123456'hashlib.md5 (hasłoA) .hexdigest () 'e10adc3949ba59abbe56e057f20f883e'hashlib.md5 (hasłoB) .hexdigest ()' e10adc3949ba59abbe56e057f20f883e ' 

A teraz dodaj sól

pre> saltA = 'qwerty'salbB =' asdfgh'passA = hasłoA + saltApassB = hasłoB + saltBhashlib.md5 (passA) .hexdigest () '086e1b7e1c12ba37cd473670b3a15214'hashlib.md5 (passBest7). / code>

To jest bardzo uproszczona wersja. Możesz dodać sól w dowolnym miejscu. Na początku / środku / końcu hasła.

Po pierwsze, jeśli dwóch użytkowników używa raczej słabego hasła „baseball”, złamanie jednego hasła w ogóle nie pomaga w złamaniu drugiego hasła ze względu na „salting”. Bez solenia złamałeś dwa hasła za cenę jednego.

Po drugie, tęczowe tabele zawierają wstępnie obliczone skróty. Więc cracker mógłby znaleźć haszysz „baseball” w tęczowej tabeli z miliardami wpisów. Znacznie szybsze niż obliczanie haszy gazylionów w tęczowej tabeli. A temu zapobiega solenie.

A teraz jedna ważna rzecz: niektórzy ludzie mają dobre hasła, inni mają złe hasła. Jeśli masz milion użytkowników i trzech używa tego samego hasła, po prostu wiesz , że hasło jest słabe. Bez solenia masz trzy identyczne skróty. Więc jeśli ktoś ukradnie twoją bazę danych skrótów, może natychmiast zobaczyć, którzy użytkownicy mają słabe hasła i skoncentrować się na ich złamaniu. O wiele łatwiej złamać „baseball” niż 1keOj29fa0romn. Bez solenia słabe hasła wyróżniają się. Dzięki soleniu cracker nie ma pojęcia, które hasła są słabe, a które trudne do złamania.

To, czy hash jest solone, czy nie, ma znaczenie tylko wtedy, gdy atakujący ma skrót hasła. Bez soli hash można zaatakować za pomocą tęczowej tabeli: wstępnie obliczonego słownika, który kojarzy hasła z hashami. Sól N-bitowa zwiększa zapotrzebowanie na pamięć dla tablicy tęczowej i czas potrzebny do obliczenia tej tabeli o współczynnik 2 ** N. Na przykład, w przypadku 32-bitowej soli, tylko jeden wpis w słowniku tęczowej tablicy, powiedzmy dla hasła passw0rd , wymaga wielu gigabajtów pamięci, co czyni tę tęczową tablicę bardzo kosztowną przy użyciu obecnego sprzętu do przechowywania danych. Więc gdy występuje sól, atakujący zostaje zredukowany do ataku siłowego na określony zestaw skrótów haseł, które zostały uzyskane.

Jednak:

• dla słabych haseł , atak siłowy zakończy się sukcesem w stosunkowo krótkim czasie.
• wystarczająco silne hasła nie zostaną znalezione w tęczowej tabeli.
• jeśli atakujący ma dostęp do skrótów, bezpieczeństwo systemu zostały już naruszone: nowoczesne systemy i protokoły nie ujawniają swoich skrótów haseł. Jeśli atakujący nie może uzyskać dostępu do bazy danych haseł, hasła mogą być równie dobrze przechowywane w postaci zwykłego tekstu.
• jeśli atakujący musi złamać zabezpieczenia systemu, aby uzyskać dostęp do skrótów w celu odwrócenia haseł z nich, jedynymi hasłami, które mają wartość dla atakującego, są te, które są ponownie wykorzystywane w innych domenach bezpieczeństwa, do których atakujący nie ma jeszcze dostępu. Hasła, które nie są ponownie wykorzystywane, nie mają żadnej wartości (a na pewno mniej wartości niż inne poufne informacje powiązane z kontami).

Powiedzmy, że użytkownik joewestlake używa hasła god1234 . Atakujący odwraca to natychmiast, używając tęczowej tabeli. (Lub w ciągu zaledwie kilku minut od złamania za pomocą ataku siłowego, jeśli hash jest zasolony, ponieważ hasło jest tak złe). Problem polega na tym, że joewestlake używał również god1234 dla swojego konta Gmail i dla bankowości internetowej, ups! Teraz atakujący czyta e-maile Joego i dowiaduje się o nim wystarczająco dużo, aby mógł łatwo odpowiedzieć na pytanie „jakie było imię Twojego pierwszego zwierzaka”, logując się do bankowości internetowej Joe.

uzasadnieniem dla soli jest to, że w pewnym stopniu chronią one użytkowników, utrudniając odwracanie haseł o średnim poziomie bezpieczeństwa: hasła, które bez soli mogłyby znaleźć się w tęczowej tablicy, ale które są wystarczająco silne że indywidualne brutalne zmuszanie ich zajmuje bardzo dużo czasu. Ale sole zapewniają tę korzyść tylko w przypadku, gdy hashe zostaną naruszone, co już stanowi poważne naruszenie bezpieczeństwa, a korzyść dotyczy tylko tych użytkowników, którzy ponownie używają swoich haseł o średnim poziomie bezpieczeństwa w innych systemach.

Powiedz Joe zamiast tego użył hasła składającego się z 10 losowych znaków alfanumerycznych i symboli. Może to nadal znajdować się w tęczowym stole, ale wymaga dużo pracy. Więc nawet jeśli Joe użył tego samego hasła do Gmaila i bankowości internetowej, dzięki soli jest bezpieczny. Cracker uruchamia swoją brutalną siłę przez może kilka godzin, może dni. Łamanie daje wiele słabych haseł od innych użytkowników tego samego systemu, którzy mają słabe hasła. Atakujący jest zadowolony z tego ustępstwa i przestaje pękać; Hasło Joe nigdy nie jest odwracane.

Ponadto, jeśli włamanie zostanie wykryte, a użytkownikom (w tym Joe) doradzi się zmianę haseł, wówczas Joe ma szansę wyprzedzić próby włamania atakującego, nawet jeśli atakujący będzie nadal atakował całą przestrzeń haseł o średnim poziomie bezpieczeństwa, która zawiera hasło Joe. Joe wie, że hasło, którego użył w zaatakowanym systemie, jest dokładnie takie samo jak hasło do Gmaila i do konta bankowego, więc próbuje zmienić te dwa pozostałe. Sól pomaga tutaj, ponieważ kupuje czas użytkownikom ponownie wykorzystującym hasła na zmianę hasła. Sól nie pomoże osobom z bardzo słabymi hasłami, które są łamane w ciągu kilku minut, ale użytkownicy haseł, których złamanie trwa godzinami lub dniami, mają szansę na walkę.