Co to jest kryptograficzna “ sól ”?

Jestem początkującym w kryptografii i chciałbym w bardzo prosty sposób zrozumieć, czym jest kryptografia ” salt ” jest, kiedy mogę go użyć i dlaczego powinienem lub nie powinienem go używać.

Czy mogę uzyskać bardzo prosty i jasne (na poziomie początkującym) wyjaśnienie?

Jeśli znasz jakieś odniesienia na ten temat, one również byłyby przydatne.

Odpowiedź

Powodem używania soli jest to, że ludzie zwykle wybierają te same hasła, a nie losowo. Wiele używanych haseł to krótkie, prawdziwe słowa, aby ułatwić ich zapamiętanie, ale to również umożliwia atak.

Jak być może wiesz, hasła na ogół nie są przechowywane w postaci zwykłego tekstu, ale raczej zaszyfrowane. Jeśli nie masz pewności co do celu funkcji skrótu, przeczytaj najpierw.

Teraz atakujący mogą po prostu wygenerować listę popularnych haseł i odpowiadające im skróty. zapisywanie skrótów przechowywanych przez witrynę w tabeli, jeśli używane są popularne hasła, ujawni je atakującemu.

A sól jest po prostu dodawany do , aby dane wyjściowe skrótu hasła były unikalne nawet dla użytkowników przyjmowanie wspólnych haseł . Jego celem jest uniemożliwienie ataków opartych na obliczeniach wstępnych. Jeśli Twoje hasło jest przechowywane z unikalną solą, to jakakolwiek wstępnie obliczona tabela haszowania haseł skierowana na niesolone skróty haseł lub kierowanie na konto z inną solą nie pomoże w złamaniu hasła twojego konta. Długi losowo wygenerowany sól (przy użyciu /dev/urandom) ma być globalnie unikalne . Dzięki temu sole mogą być używane do -computation ataki całkowicie nieskuteczne.

Najprostszym sposobem połączenia soli i hasła jest po prostu ich połączenie, tj. przechowywana wartość skrótu to Hash(salt||password). hasło password1 teraz w magiczny sposób staje się, np. 6$dK,3gCA%Jpassword1, które jest mało prawdopodobne, aby znaleźć się w tabeli łamacza haseł.

Sól można przechowywać w całości w bazie danych, obok wartości zakodowanej. Gdy atakujący ma bazę danych i chce znaleźć hasła, musi wygenerować wstępnie obliczoną tabelę dla każdej soli z osobna. Jest to kosztowna operacja.

Innym sposobem ochrony przed złamaniem haseł offline jest wykonanie rozciąganie hasła, tj. spowolnienie obliczania skrótu hasła dla dowolnej osoby, w tym usługi logowania i programów do łamania haseł. Jedną z metod rozciągania haseł jest wielokrotne iterowanie funkcji skrótu, tj. Przechowywanie Hash(Hash(Hash(Hash…(Hash(salt||password)))…).

Inną popularną koncepcją związaną z soleniem jest pieprz . To znaczy kolejna losowa wartość połączona z hasłem, tak że przechowywana wartość to Hash(pepper||salt||password). Papryka jest wtedy w ogóle nie jest przechowywana . Zarówno serwer logowania, jak i narzędzie do łamania haseł muszą brutalnie wymusić nieznaną wartość pieprzu, spowalniając porównywanie skrótów haseł dla obu stron.

Od 2013 do 2015 r. haszowanie hasła zorganizowano konkurs w celu znalezienia lepszego algorytmu rozciągania hasła. Zwycięzcą został algorytm Argon2 . Zaleca się programistom używanie Argon2 zamiast implementowania własnego algorytmu .

Komentarze

  • Więc zasadniczo, kiedy masz tylko jedno lub 2 hasła zapisane w bazie danych, użycie soli jest praktycznie bezużyteczne? Rozumiem, że jest to pomocne tylko wtedy, gdy liczba haseł przechowywanych w bazie danych nie jest mała.
  • @AbhinavChoudhury: Nie, chroni przed tęczowymi tabelami – tj. Wstępnie obliczonymi tabelami dla określonego skrótu. Przykład: weź hasło ” hasło1 „. Jeśli nie ' nie solisz, ' nie przechowujesz HASH (” hasło1 „) w Twojej bazie danych. Teraz, jeśli atakujący uzyska Twoje dane i wstępnie obliczył HASH (*) dla wszystkich 9-znakowych haseł, może odzyskać hasło. Jeśli zamiast tego podałeś hasło, HASH (' somesaltforyou ' || ' password1 ') NIE będzie w tęczowej tabeli atakujących (ponieważ ' ma więcej niż 9 znaków).
  • ” Sól można przechowywać w czystej postaci w bazie danych, obok zaszyfrowanej wartości ” – – ta część nigdy nie miała dla mnie sensu; Zastanawiałem się, czy mógłbyś to rozwinąć
  • Chodzi o to, aby upewnić się, że hash nie zostanie znaleziony we wstępnie obliczonej tabeli. Musi zostać zapisane, aby zweryfikować hasło (w przeciwnym razie ' sa ” pepper „). Sól nie powinna być ” tajna „, tylko po to, aby hasło było unikalne. Oznacza to oczywiście, że każde zapisane hasło musi mieć swoją własną, niepowtarzalną (i losową) sól.

Odpowiedź

Czy możesz mi pomóc zrozumieć, czym jest kryptograficzna „sól”?

W kontekście hasła „sól” to dane (losowe lub inne) dodane do funkcji skrótu w celu utrudnienia złamania zaszyfrowanego wyjścia hasła.

Kiedy mogę go użyć?

Zawsze.

Dlaczego powinienem czy nie powinienem tego używać?

Zawsze powinieneś używać wartości salt z funkcjami haszującymi, z powodów wyjaśnionych poniżej.

Generalnie prawdą jest, że ludzie wybierają słabe hasła i z pewnością prawdą jest, że istnieją gigabajty publicznie dostępnych tabel tęczowych , pełnych zaszyfrowanych wartości, które je reprezentują. Więc kiedy ktoś tworzy konto w Twojej usłudze i wybiera hasło, aby zabezpieczyć swoją tożsamość, zazwyczaj możesz założyć, że wybrane przez niego hasło będzie 1) powszechne, 2) niezabezpieczone i 3) dostępne do odsyłaczy w tabelach wyszukiwania. >

Na przykład hasło Nowayin1 po zahaszowaniu przez MD5 to 6f367d65bc74b88e21fb9959487ffa3a i oczywiście nie jest dobrym wyborem. Nawet jeśli może wyglądać w porządku (i tak nie jest), fakt, że hash MD5 hasła pojawia się w otwartych bazach danych, czyni go bezwartościowym.

Ale to tylko 128-bitowe MD5. Co z czymś silniejszy, jak SHA1 (160-bitowy) czy nawet Whirlpool (512-bitowy)?

Ten sam problem.

Na przykład P @ $$ słowo z SHA1 to 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 i 1qazXSW @ zakodowanego z Whirlpool 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf .

Głównym problemem związanym ze wszystkimi tymi hasłami i miliardami innych haseł jest fakt, że ich powszechnie używane skróty stały się powszechnie znane.

Hasło sól zmienia to.

Jeśli do wybranego hasła użytkownika została dodana losowa wartość (sól), wtedy skrót SHA1 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 nie będzie już ujawniał P @ 703de9e2ce „> jako hasło użytkownika, ponieważ wartość skrótu w tabeli tęczy nie będzie już do niego pasować.

I nie zajęłoby to dużo czasu. Na przykład mała 16-bitowa wartość losowa przyniosłaby 65 536 wariantów każdej zaszyfrowanej wartości w tabelach przeglądowych. Tak więc baza danych zawierająca 15 miliardów wpisów wymagałaby teraz ponad 983 miliardów hashów, aby uwzględnić sól.

Tak więc, to jest punkt solenia twoich haszów, aby udaremnić wyszukiwanie i tęczowe tablice. Ale nie „Nie wieszaj kapelusza na zasolonym haszu, ponieważ hakerzy nie będą tracić czasu na używanie tęczowych tabel do ustalania haseł.

Będą używać system klastrów 25-GPU z pięcioma serwerami i Hashcat, który może przepalać 350 miliardów prób na sekundę, łamiąc skróty dla każdego możliwego ośmioznakowego hasła zawierającego wielkie i małe litery, cyfry i znaki specjalne sześć godzin. (I to było w 2012 roku).

Techniki takie jak rozciąganie klawiszy, które powodują, że skróty działają wolniej, można wykorzystać do zrównoważenia szybkości takiego sprzętu, sprawiając, że ataki słownikowe i brutalne siły są zbyt wolne, aby były opłacalne , ale sprzęt staje się coraz szybszy.

UPDATE 2018:

Aktualne sprawdzone metody obejmują bezpieczne szyfrowanie haseł za pomocą Argon2i (preferowanego zamiast scrypt), funkcji wymagającej dużej ilości pamięci, która jest bardzo odporny na FPGA, wielordzeniowe procesory graficzne i dedykowane moduły ASIC używane do łatwego łamania nierozciągniętych haseł. W PHP7 implementacji Argon2 sól jest obsługiwana wewnętrznie za Ciebie.

Odpowiedź

Spróbuję odpowiedzieć na część twojego pytania, które do tej pory było lekceważone:

kiedy mogę go użyć i dlaczego powinienem / nie powinienem go używać.

Krótka odpowiedź jest taka, że jako amator nie powinieneś używać kryptografii na poziomie, który wymaga bezpośredniego zajmowania się solami.

Na przykład bcrypt algorytm haszowania haseł wewnętrznie używa soli. Ale nie ujawnia tego faktu programistom używającym go – wystarczy przekazać hasło do bcrypt (i opcjonalnie do parametru, który ustawia „poziom siły procesora „potrzebne do wygenerowania skrótu) i zwraca wartość skrótu. Kiedy chcesz sprawdzić, czy hasło jest poprawne, przekazujesz bcrypt zarówno hasło, jak i wygenerowany wcześniej skrót. Wskaże, czy hasło zostało użyte do wygenerowania skrótu.

Nie stosuj się do porad podanych tutaj i spróbuj zaszyfrować własne hasła za pomocą soli. Jest to niskopoziomowy szczegół implementacji, a jeśli stwierdzisz, że pracujesz na poziomie, na którym tego rodzaju rzeczy są potrzebne, pracujesz na zbyt niskim poziomie abstrakcji. Kryptografia jest bardzo trudna do wykonania poprawnie, a Internet jest całkowicie zaśmiecony programistami o dobrych intencjach, „całkowicie niezabezpieczonymi schematami mieszania haseł w domu.

Odpowiedź

Cytując „ Nr egzaminu 70-486 Developing ASP.NET MVC 4 Web Applications (MCSD): Developing ASP.NET MVC 4 Web Applications ” autor: William Penberthy, Pearson Education, 15 września 2013:

Salting to proces, który wzmacnia szyfrowanie plików i skróty, utrudniając ich złamanie. Salting dodaje losowy ciąg na początku lub na końcu tekstu wejściowego przed haszowaniem lub zaszyfrowaniem wartości. Na przykład przy próbie złamania listy haseł hakerzy muszą uwzględnić sól, a także możliwe informacje o haśle, zanim będą mogli złamać do aplikacji. Jeśli każdej solonej wartości zostanie przypisana inna wartość soli, możliwość utworzenia tabeli potencjalnych wartości haseł dla pa program do łamania haseł staje się nieporęczny.

Odpowiedź

Sól to losowa liczba potrzebna do uzyskania dostępu do zaszyfrowanych danych, wraz z hasłem.

Jeśli atakujący nie zna hasła i próbuje je odgadnąć za pomocą ataku siłowego, to każde hasło, które spróbuje należy wypróbować z każdą wartością soli.

Tak więc dla jednobitowej soli (0 lub 1) sprawia to, że szyfrowanie jest dwa razy trudniejsze do złamania w ten sposób. Dwubitowa sól sprawia, że jest cztery razy trudniejsza, trzy-bitowa sól osiem razy trudniejsza itd. Możesz sobie wyobrazić, jak trudno jest złamać hasła przy użyciu szyfrowania wykorzystującego 32-bitową sól!

Komentarze

  • Nie. Zwykle zakłada się, że napastnik zna sól. W tym przypadku po przekroczeniu pewnego niskiego progu sól nie poprawia bezpieczeństwa.
  • ” Zakłada się, że atakujący zna sól ” – > Kto to zakłada?
  • @Mike: Kto? Ktoś mówi ” Należy zawsze zakładać, że atakujący zna sól. „. Osoby na innej stronie mówią o ” Sole są publiczne ” i później mówi, że ” sole są znane, ponieważ ' jest branżowym standardem użycia słowa sól. ” Inny mówi, że ” sól jest publicznie znana lub przynajmniej powinna być traktowana jako publiczna wiedza. „.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *