Nie przechowywanie soli to zła rada.

Głównym celem soli jest to, że każde hasło użytkownika musi być atakowane indywidualnie.

Jeśli nie przechowujesz soli, wtedy , jak powiedziałeś, musisz wypróbować każdą kombinację soli, aby zweryfikować hasło. Jeśli musisz sprawdzić każdą kombinację soli, oznacza to, że sól nie może być zbyt długa (wspomniałeś w komentarzu o 12 bitach). Jeśli sól nie jest długa, oznacza to, że sól będzie powtarzana dla wielu użytkowników. Jeśli powtórzy się to dla wielu użytkowników, oznacza to, że atakujący będzie mógł zaatakować wielu użytkowników w tym samym czasie, co pozwoli mu zaoszczędzić czas.

W ten sposób prawie całkowicie pokonujesz cel używania sól.

„Sekretna” sól jest znana jako pieprz.

Z Wikipedii:

Pieprz można dodać do hasła w dodatek do wartości soli. Papryka pełni podobną rolę jak sól, jednak podczas gdy sól jest powszechnie przechowywana obok wartości mieszanej, aby coś można było zdefiniować jako pieprz, powinno spełniać jedno z następujących kryteriów, które ją definiują, bardziej starannie ukryty `` sekret '' niż wartość soli:

• Pieprz jest trzymany oddzielnie od wartości do zaszyfrowania
• Pieprz jest generowany losowo dla każdej wartości do zaszyfrowania (w ramach ograniczonego zestawu wartości) i nigdy nie jest przechowywany. Kiedy dane są testowane pod kątem zaszyfrowanej wartości dla dopasowania, odbywa się to poprzez iterację zestawu wartości ważnych dla pieprzu, a każda z nich jest z kolei dodawana do danych do testowania (zwykle przez dodanie sufiksu do danych), przed uruchomieniem kryptograficznej funkcji skrótu na połączonej wartości.

Zaletą pieprzu jest to, że atakujący musi teraz odgadnąć do liczby możliwych permutacji wartości pieprzu dla każdego wpisu w postaci zwykłego tekstu.

Papryka zwiększa długość ataku dla określonego skrótu, podczas gdy sól nie.

Pamiętaj, że sól jest skutecznym złagodzeniem dla wstępnie obliczonych skrótów i sprawia, że atakujący spędza dużo czasu na atakowaniu zestawu skrótów. Jeśli jednak chodzi tylko o jeden hash i nie ma być używany żaden wstępnie obliczony hash, sól nie wydłuża czasu ataku. Jednak Pepper zmusza atakującego do wielokrotnego odgadnięcia dla każdego hasła w postaci zwykłego tekstu, nawet dla jednego skrótu.

W ten sposób pieprz jest podobny do rozciągania klawiszy.

Większość implementacji preferuje rozciąganie klucza niż pieprz.

Z mojej osobistej obserwacji wynika, że ​​większość implementacji woli rozciąganie klawiszy od papryki. Nie mam odniesienia do tego, więc czytelnicy mogą podawać w komentarzach odniesienia wspierające lub przeciwne. Ludzie wolą rozciąganie klucza, ponieważ ma znane i oczekiwane korzyści w zakresie wydajności i bezpieczeństwa. Aby obliczyć N-tą rundę skrótu, należy obliczyć N haszów. Jednak za pomocą pieprzu można obliczyć tylko oczekiwaną liczbę prób. Rozważmy 1-bajtowy pieprz, atakujący potrzebowałby 256 prób, aby odgadnąć wszystkie możliwe kombinacje, ale wartość oczekiwana to 128, a atakujący mógłby (średnio 1/256 razy) odgadnąć wartość na pierwsza próba.

Papryka i rozciąganie klawiszy mogą działać przeciwko sobie.

Rozciąganie klawiszy jest efektywne, ponieważ można ustawić liczbę rund na podstawie czasu, w którym obliczenie skrótu ma być brać. Załóżmy, że chcesz, aby pojedynczy test trwał pół sekundy na bieżącym sprzęcie, po prostu zwiększaj liczbę rund, aż to nastąpi.

Jeśli chodzi o pieprz, ponieważ musisz odgadnąć wiele wartości dla każdego hasła, rozmiar pieprzu musi być odwrotnie proporcjonalny do liczby rund, aby utrzymać stały czas obliczeń.

Praktyczne porady dotyczące implementacji haszowania

Najlepszą radą przy implementacji haseł / haszowania jest użycie dobrze znanych metodologii i przetestowanych bibliotek. Powinieneś używać bcrypt lub pbkdf2 z unikalną solą i wieloma rundami. Te algorytmy mają zwykle dobrze znane implementacje w wielu językach i strukturach. Jeśli zdarzy ci się znaleźć dobrze znaną i przetestowaną bibliotekę, która zawiera pieprz, oprócz soli i rozciągania klawiszy, może warto poświęcić trochę czasu, ale dodatkowe korzyści często przewyższają koszty wydajności.

Tło: powinieneś używać powolnego skrótu hasła. (tj. bcrypt) Przez „powolne” mam na myśli kosztowne obliczeniowo, wymagające ponad 100 ms (na twoim sprzęcie) ^{z ochroną DoS *} na przetestowanie pojedynczego hasła. Ma to na celu zwiększenie mocy obliczeniowej potrzebnej (na sprzęcie atakującego) do znalezienia hasła brutalną siłą, gdyby hash został skradziony.

Unikalna sól dla użytkownika jest wysoce zalecana. (w przypadku bcrypt jest on generowany automatycznie) Sól powinna być wysoce unikalna (tj. długa losowa &), ale nie tajna . Używanie unikalnej soli oznacza, że ​​atakujący musiałby wykonać oddzielne zadanie brutalnej siły dla każdego użytkownika .

Gdyby nie było „soli”, atakujący mógłby natychmiast użyć Rainbow Table i żadnej brutalnej siły.

Jeśli używasz tylko „wspólnej soli”, osoba atakująca może złamać hasła wszystkich użytkowników za pomocą jednego brutala wymuś Hioba. (nie tak szybki jak tęczowy stół, ale wciąż znacznie łatwiejszy niż osobna praca brutalna dla każdego z nich)

Odpowiedź: Gdybyś nie przechowywał sól („brutalnie wymuś hash w czasie wykonywania”, jak sugeruje twój profesor)

• możliwych soli musiałoby być bardzo mało
• wartość hash musiałaby być całkiem sporo szybciej

To całkowicie zniweczyłoby cel soli, poważnie osłabiając korzyści płynące z Slow hash. To poważny błąd projektowy pana profesora. Zasadniczo rozwija swój własny schemat przechowywania haseł, w którym powinien używać dobrze sprawdzonego algorytmu bcrypt (lub scrypt lub PBKDF2) zgodnie z przeznaczeniem .

_{* Jak skomentował @Navin, byłby to potencjalny wektor ataku DoS. Jednym z rozwiązań jest ograniczenie liczby godzinowych prób na adres IP i na nazwę użytkownika. Możliwe jest również, że powinieneś zmniejszyć „powolność” swojego haszyszu do zaledwie 10 ms. To nie jest tak dobre jak 100 ms z perspektywy „skradzionego skrótu”, ale wciąż znacznie lepsze niż „mikrosekundy”.}

Twój profesor nie ma racji. Chodzi o to, aby zwiększyć entropię haszowanych haseł, aby zapobiec wszelkim atakom na nie przed obliczeniami, a także zapobiec temu, aby to samo hasło od różnych użytkowników miało tę samą wartość skrótu.

Możliwość wypróbowania wszystkich możliwych wartości soli oznacza, że ​​musisz mieć bardzo NISKĄ ilość entropii w soli, co oznacza, że ​​możliwe są obliczenia wstępne za pomocą tabel tęczowych.

W ten sposób możesz użyć soli. Byłby to rodzaj procesu rozciągania haszyszu. Zwykle hasz jest rozciągany, powtarzając algorytm kilka tysięcy razy, co 1000-krotnie spowalnia atakujących i użytkowników, ale użytkownicy zazwyczaj nie mają nic przeciwko spowolnieniu. Użycie soli w ten sposób spowodowałoby wykonanie algorytmu rozciągania skrótu, ponieważ musiałoby powtarzać go dla wielu nieznanych wartości.

Jest to jednak niezwykle niezwykłe podejście. Tradycyjne metody solenia robią to, co powinny robić sole o wiele lepiej (spraw, aby nikt nie mógł wstępnie obliczyć tabeli haseł). Tradycyjne sposoby rozciągania skrótu robią to, co powinno dawać znacznie lepsze wyniki (sprawić, by obliczanie haseł zajęło atakującym więcej czasu). Używanie soli w ten sposób jest jakby zmiksowaniem ich obu razem. Rezultat jakby działa, ale czystsze podejścia dają oba rozwiązania dużo lepiej niż brzydka pomyłka technik.

Zamiast myśleć o soli w kategoriach brutalnego wymuszania, wolę myśleć o niej w kategoriach stwierdzenia, że ​​nie można powiedzieć nic o haśle, w tym o jego związku z innymi hasłami, patrząc na nie. Jeśli system nie używa haseł, sprawdzenie zaszyfrowanych haseł dwóch użytkowników wskazałoby, czy ich prawdziwe hasła są zgodne. Jeśli system wykorzystywał tylko nazwę użytkownika, ale nic losowego, określonego w czasie ani specyficznego dla systemu, to sprawdzenie zaszyfrowanych haseł użytkownika na dwóch maszynach, które stosują to samo podejście, wskaże, czy hasła użytkownika na dwóch komputerach są zgodne. Jeśli system posłuży się identyfikatorem systemu i nazwą użytkownika, ale nie ma nic losowego ani określonego w czasie, wówczas ktoś, kto ma dostęp do dwóch różnych skrótów haseł tego samego użytkownika, może stwierdzić, czy powiązane hasła są zgodne.

Efekt losowe solowanie ma na celu zapewnienie, że żadne dwa skróty używające tego samego hasła nie będą pasować, nawet jeśli dotyczą tego samego użytkownika w tym samym systemie. Chociaż można by osiągnąć podobny efekt bez przechowywania soli, gdyby próby logowania miały na celu ich brutalne wymuszenie, takie podejście ograniczyłoby praktyczną długość soli, której można by użyć, a tym samym zwiększyłoby prawdopodobieństwo, że hasła używane w dwóch kontekstach miałyby taką samą sól i dzięki temu będzie rozpoznawalny jako pasujący.

Co daje solenie? Atakujący mają wstępnie obliczone bazy danych wartości skrótu dla haseł, wspólnych i nie. Jeśli przechwytują twoją bazę danych i mają skrót haseł dla każdego użytkownika, łatwo jest porównać ich skróty z tymi wartościami bez soli.

Z losową solą przechowywaną wraz z hasłem, to szalenie metoda szybka nie jest już możliwa. Ale jeśli atakujący ma zarówno sól, jak i hash, nadal można używać ataków słownikowych w przypadku słabych haseł lub brutalnego forsowania w przypadku krótkich. Atakujący musi tylko użyć soli i wypróbować różne hasła za pomocą słownika lub ataku brute-force.

Teraz powiedzmy, że kiedy hasło jest zmieniane, haszujesz je losową 12-bitową wartością, która jest To znaczy nie jest przechowywane razem z solą. Następnie za każdym razem, gdy sprawdzasz hasło, musisz wypróbować wszystkie 4096 wartości. Na moim komputerze zajmuje to około 3,5 ms, więc co sekundę można sprawdzić 284 hasła. Trochę więcej wykorzystania procesora na serwerze, gdy ktoś się loguje, ale dla kogoś, kto próbuje ataków słownikowych lub brutalnej siły, po prostu utrudniłeś mu pracę, nawet jeśli ma hash i sól.

Wydaje się, że pomysł nieprzechowywania pewnej kontrolowanej liczby bitów soli, która jest niezależnie konfigurowana i niezależna od rozmiaru soli, ma jakąś wartość.

Załóżmy, że mamy 32-bitowe sole. Mogliśmy zdecydować się na przechowywanie tylko 22 bitów i brutalnej siły przez pozostałe 10 podczas uwierzytelniania. Efekt jest taki, jakby do funkcji haszującej dodano więcej rund. Nie tak wiele, że ma to wpływ na legalne uwierzytelnianie, ale wystarczająco dużo, aby zwiększyć trudność łamania brutalnej siły.

W przyszłym roku maszyny będą szybsze. Więc przeglądamy bazę danych haseł i usuwamy trochę z każdej soli: teraz przechowujemy tylko 21 bitów i musimy brutalnie przesuwać się przez 11.

To tak, jakbyśmy podwoili siłę mieszania, ale bez zakłócenie zastępowania algorytmu i nakłanianie użytkowników do ponownego mieszania haseł (co jest pozostawione regularnej polityce wygaśnięcia hasła).

To podejście „stopniowego odrzucania soli” może wydłużyć żywotność funkcji mieszających.

Jednak tego rodzaju podejścia spowalniają legalne uwierzytelnianie i ataki brute force w równym stopniu, więc w najlepszym przypadku zapewniają mniejszą warstwę bezpieczeństwa. Powinniśmy skupić się na ulepszeniach, które dodają tylko stałą ilość dodatkowego czasu do legalnego użycia, jednocześnie zwiększając trudność pękania. Oczywiście ulepszeniem, które ma tę właściwość, jest zwiększenie ilości entropii w haśle! Każdy bit entropii dodany do hasła powoduje stały koszt dla uprawnionych użytkowników, ale podwaja wysiłek związany z brutalnym łamaniem hasła. Hasło o długości N wymaga O (N) do skrótu (i wpisania), ale O (2 ** N) do brutalnej siły. Dodanie 12 bitów entropii do hasła pokonuje ukrywanie 12 bitów soli.

Na wolności mamy tabelę użytkowników. Tabela użytkowników to zwykle

  ID | nazwa użytkownika | sól | zaszyfrowane_hasło | horridly_insecure_reset_key =================================================== ========================== 1 | użytkownik1 | foo | 09b6d39aa22fcb8698687e1af09a3af9 | NULL2 | użytkownik2 | bar | 6c07c60f4b02c644ea1037575eb40005 | NULL3 | użytkownik3 | baz | 09b6d39aa22fcb8698687e1af09a3af9 | reset  

Wtedy metoda uwierzytelniania będzie wyglądać mniej więcej tak:

  def authentication (user, password) u = User.find (user: user) return u. encrypted_password == encrypt (hasło + u.salt) end  

Posiadanie soli na użytkownika zapewnia, że ​​nawet jeśli znane jest hasło użytkownika 1, nie można znaleźć hasła użytkownika 2 lub użytkownik3 bez ich soli.

Aby upewnić się, że nie możesz rozwiązać problemu, masz zestaw zaszyfrowanych haseł i wypróbowując kilka zaszyfrowanych haseł.

W ten sposób każdy atak na użytkownik musi być uruchomiony od zera.

Nawet jeśli napastnik ma listę użytkowników i soli, nadal musi dokonać włamania do każdego użytkownika, aby sprawdzić, czy ma pasujące hasło. Gdybyś miał pulę soli lub jedną statyczną sól, mógłbym wiedzieć, że hasło użytkownika 1 to hasło, a następnie po prostu znaleźć wszystkie zaszyfrowane hasła, które pasują. Więc w ten sposób przynajmniej trochę je spowalnia.

Teraz, gdy patrzymy na sole, chcemy ograniczyć ponowne użycie soli. Dwie identyczne sole ułatwią napastnikom. Jeśli dwie osoby mają tę samą sól i to samo hasło, złamanie jednego użytkownika spowoduje złamanie drugiego.

Powiedzmy, że używamy tylko tych trzech soli. Mamy 3000 użytkowników. oznacza to, że 1000 osób ma tę samą sól. Jeśli 1% z nich ma hasło „hasło”, wówczas wszystkie te osoby mogą zostać złamane w tym samym czasie. 10 kont zostaje zhakowanych jednocześnie. Ponieważ znamy te trzy sole. To bardzo łatwy odcinek, aby zaatakować 30 osób jednocześnie.

Teraz, jeśli każda sól jest wyjątkowa. Wiemy, że hasło użytkownika 1 to hasło, ale to nic nie da. Nadal złamałeś tylko 1 użytkownika. Nadal musisz zrobić „czy hasło + sól = zaszyfrowane hasło” dla wszystkich pozostałych 2999 użytkowników.

Naprawdę ważna uwaga.

Bezpieczeństwo poprzez zaciemnienie to nie bezpieczeństwo. To nie znaczy, że powinieneś publikować tabelę użytkowników w Google, bo to głupie. Jednak mierząc poziom bezpieczeństwa, należy założyć, że osoba atakująca ma wszystko. Nie możesz powiedzieć: „Ale oni nie będą znali soli aplikacji, ponieważ nie mają kodu źródłowego”. Bo mogli. Nie oznacza rozdawania soli, po prostu oznacza, że ​​nie jest to prawdziwe zabezpieczenie. Załóżmy, że mają nazwę użytkownika i sól, a następnie spróbuj utrudnić im uzyskanie hasła.

BARDZO WAŻNA UWAGA

użyty tutaj kod i tabela są około 9 000 razy zbyt proste do rzeczywistego użycia. Hasło nie jest zaszyfrowane, sole są zbyt krótkie, metoda jest trochę za uproszczona, w skrócie robienie czegoś takiego na produkcji nie jest czymś, co należy uznać za bezpieczne. Wybrałem te przyczyny, które są proste dla celów demonstracyjnych, a nie dlatego, że są bezpieczne.