Generowanie soli i oprogramowanie open source

ponieważ pytania dotyczące solenia hashów pojawiają się dość regularnie i wydaje się, że w tym temacie jest trochę zamieszania, rozszerzyłem tę odpowiedź.

Salt to losowy zbiór bajtów o stałej długości, który jest dodawany do wejścia algorytmu hashowego.

Dlaczego solenie (lub siew) hash jest przydatne?

Dodanie losowej soli do hasha gwarantuje, że to samo hasło wytworzy wiele różnych skrótów. Sól jest zwykle przechowywana w bazie danych, wraz z wynikiem funkcji hash. Solenie haszu jest dobre z wielu powodów:

W przeciwieństwie do innych ataków z precomputated attacks, atak ten nie może być atakowany z precomputated attacks.]}
1. Solting upewnia się, że to samo hasło nie powoduje tego samego hasha. Dzięki temu nie można ustalić, czy dwóch użytkowników ma to samo hasło. I, jeszcze ważniejsze , TY nie można określić, czy ta sama osoba używa tego samego hasła w różnych systemach.
2. [[30]}Solowanie zwiększa złożoność haseł, tym samym znacznie zmniejszając skuteczność obu Słownik- oraz ataki urodzinowe. (jest to prawdą tylko wtedy, gdy sól jest przechowywana oddzielnie od hash).
3. właściwe solenie znacznie zwiększa zapotrzebowanie na przechowywanie ataków precomputation, aż do punktu, w którym są to już nie jest praktyczne. (8-znakowe hasła alfanumeryczne z 16-bitowym salt, zahaszowane do 128-bitowej wartości, zajmowałyby tuż pod 200 exabajty bez redukcji tęczy).

Salt nie jest tajnym kluczem, zamiast tego salt 'działa', czyniąc funkcję skrótu specyficzną dla każdej instancji. W przypadku salted hash nie ma jednej funkcji hash, ale jedna dla każdej możliwej soli wartość. Uniemożliwia to atakującemu atakowanie N hashowanych haseł za mniej niż N koszt ataku jednego hasła. O to chodzi z solą.
"Tajna sól" nie jest solą, nazywa się ją" kluczem " i oznacza, że nie obliczasz już hasha, ale kod uwierzytelniający Message Authentication Code (MAC). Komputer MAC to skomplikowana sprawa (znacznie trudniejsza niż łączenie klucza i wartości w funkcję haszującą) i jest to zupełnie inny temat / align = "left" /

Sól musi być losowa dla każdego przypadku, w którym jest używana. Zapewnia to, że atakujący musi atakować każdy solony hash oddzielnie.
Jeśli polegasz na tym, że Twój algorytm soli (lub soli) jest tajny, wkraczasz do sfer bezpieczeństwa poprzez zaciemnienie (nie zadziała). Najprawdopodobniej nie otrzymujesz dodatkowej ochrony od tajemnicy solnej; po prostu dostajesz ciepłe, rozmyte uczucie bezpieczeństwa. Więc zamiast uczynić Twój system bezpieczniejszym, po prostu odciąga cię od rzeczywistości.

Technicznie rzecz biorąc, sól powinna być unikalna . Znaczenie soli ma być różne dla każdego hashowanego hasła. To znaczy na całym świecie . Ponieważ nie ma centralnej organizacji, która rozprowadza unikalne Sole na żądanie, musimy polegać na następnej najlepszej rzeczy, którą jest losowy wybór z nieprzewidywalnym generatorem losowym, najlepiej w przestrzeni soli wystarczająco dużej, aby kolizje nieprawdopodobne(dwie instancje używające tej samej wartości soli).

Kuszące jest czerpanie soli z pewnych danych, które są "przypuszczalnie unikalne", takich jak ID użytkownika, ale takie schematy często zawodzą z powodu paskudnych szczegółów:

1. Jeśli użyjesz na przykład ID użytkownika , niektórzy źli ludzie, atakujący różne systemy, mogą po prostu połączyć swoje zasoby i utworzyć wstępnie obliczone tabele dla identyfikatorów użytkowników od 1 do 50. Identyfikator użytkownika jest unikalny w całym systemie, ale nie na całym świecie .

2. To samo dotyczy nazwy użytkownika : istnieje jeden "root" na system uniksowy, ale na świecie jest wiele korzeni. Tęczowy stół dla "korzeni" byłby wart wysiłku, ponieważ mógłby być zastosowany do milionów systemów. Co gorsza, istnieje również wiele "bob", a wielu nie ma szkolenia sysadmin: ich hasła mogą być dość słabe.

3. Wyjątkowość jest również czasowa. Czasami użytkownicy zmieniają swoje hasło. Dla każdego należy wybrać nowe hasło, a Nowa Sól. W przeciwnym razie atakujący uzyska hash starego hasła, a hash nowego może próbować zaatakować oba jednocześnie.

Użycie losowej soli otrzymanej z zabezpieczonego kryptograficznie, nieprzewidywalnego PRNG może być pewnego rodzaju przesadą, ale przynajmniej to provably chroni Cię przed wszystkimi tymi zagrożeniami. Nie chodzi o to, żeby napastnik nie wiedział, czym jest osoba , to o tym, aby nie dać im dużego, tłustego celu, który będzie używany na znacznej liczbie potencjalnych celów. Losowy wybór sprawia, że cele są tak cienkie, jak jest to praktyczne.

Podsumowując:

Użyj losowej, równomiernie rozłożonej, wysokiej entropii soli. Używaj Nowej Soli za każdym razem, gdy tworzysz nowe hasło lub zmieniasz hasło. Przechowywać sól wraz z hashed hasło. Preferuj Duże sole (co najmniej 10 bajtów, najlepiej 16 lub więcej).

Sól nie zmienia złego hasła do dobrego hasła. Upewnia się tylko, że atakujący zapłaci przynajmniej cenę ataku słownikowego za każde złe hasło, które złamie.

przydatne źródła:
stackoverflow.com: nieprzypadkowa sól dla hashów haseł
Bruce Schneier: praktyczna Kryptografia (książka)
Matasano Security: dość tych tęczowych stołów
usenix.org: Unix crypt używał soli od 1976
owasp.org: Po co dodawać sól
openwall.com: Sole

Zastrzeżenie:
Nie jestem ekspertem od bezpieczeństwa. (Chociaż ta odpowiedź została przejrzana przez Thomas Pornin )
Jeśli któryś z specjalistów ds. bezpieczeństwa znajdzie coś nie tak, proszę skomentuj lub Edytuj tę odpowiedź na wiki.

Odkąd Unix stał się popularny, właściwym sposobem przechowywania hasła jest dodanie losowej wartości (salt) i hashowanie go. Oszczędzaj sól tam, gdzie możesz dostać się do niej później, ale tam, gdzie masz nadzieję, że źli go nie dostaną.

To ma dobre efekty. Po pierwsze, źli ludzie nie mogą po prostu zrobić listy oczekiwanych haseł, takich jak" Password1", hashować ich w tęczowej tabeli i przeglądać pliku haseł w poszukiwaniu dopasowań. Jeśli masz dobrą sól dwubajtową, muszą wygenerować 65,536 wartości dla każdego oczekiwanego hasła, a to czyni tęczową tabelę o wiele mniej praktyczną. Po drugie, jeśli możesz trzymać sól z dala od złych facetów, którzy patrzą na Twój plik hasła, znacznie utrudniłeś obliczanie możliwych wartości. Po trzecie, uniemożliwiłeś bandziorom ustalenie, czy dana osoba używa tego samego hasła na różnych stronach.

Aby to zrobić, generujesz losową sól. Powinno to wygenerować każdą liczbę w pożądanym zakresie z jednolitym prawdopodobieństwo. Nie jest to trudne; prosty liniowy kongruencyjny generator liczb losowych dobrze się sprawdzi.

Jeśli masz skomplikowane obliczenia, aby zrobić sól, robisz to źle. Jeśli obliczysz to na podstawie hasła, robisz to źle. W takim razie wszystko, co robisz, to komplikowanie hasha, a nie dodawanie soli.

Nikt dobry w ochronie Nie polegałby na ukrywaniu algorytmu. Współczesna kryptografia opiera się na algorytmach, które zostały szeroko przetestowane, a aby były szeroko przetestowane, muszą być dobrze znane. Ogólnie rzecz biorąc, stwierdzono, że bezpieczniej jest używać standardowych algorytmów, a nie obracać własne i mieć nadzieję, że jest to dobre. Nie ma znaczenia, czy kod jest open source, czy nie, nadal często źli ludzie mogą analizować, co robi program.

Możesz po prostu wygenerować losową sól dla każdego rekordu w czasie wykonywania. Załóżmy na przykład, że przechowujesz hashowane hasła użytkowników w bazie danych. Możesz wygenerować 8-znakowy losowy ciąg małych i dużych znaków alfanumerycznych w czasie wykonywania, poprzedzać go hasłem, hash that string i przechowywać go w bazie danych. Ponieważ są 62⁸ możliwe sole, generowanie tabel tęczowych (dla każdej możliwej soli) będzie zbyt drogie, a ponieważ używasz unikalnego salt dla każdego rekordu hasła, nawet jeśli atakujący wygenerował parę pasujących do tęczowych tabel, nadal nie będzie w stanie złamać każdego hasła.

Możesz zmienić parametry generowania soli w zależności od potrzeb bezpieczeństwa; na przykład możesz użyć dłuższej soli lub wygenerować losowy ciąg zawierający znaki interpunkcyjne, aby zwiększyć liczbę możliwych soli.

Użyj Generatora funkcji losowych, aby wygenerować salt i zapisać go w bazie danych, dodać salt po jednym wierszu i zapisać go w bazie danych.

Podoba mi się, jak salt jest generowany w django-Rejestracja. Numer referencyjny: http://bitbucket.org/ubernostrum/django-registration/src/tip/registration/models.py#cl-85

salt = sha_constructor(str(random.random())).hexdigest()[:5]
activation_key = sha_constructor(salt+user.username).hexdigest()
return self.create(user=user,
           activation_key=activation_key)

Używa kombinacji sha wygenerowanej przez losową liczbę i nazwę użytkownika, aby wygenerować hash.

Sha sama jest dobrze znana z tego, że jest silna i nie do złamania. Dodaj wiele wymiarów, aby wygenerować samą sól, z losową liczbą, sha i komponentem specyficznym dla użytkownika, masz niezniszczalne bezpieczeństwo!

W przypadku aplikacji desktopowej, która szyfruje dane i wysyła je na zdalny serwer, jak rozważyć użycie za każdym razem innej soli?

Używając PKCS # 5 z hasłem użytkownika, potrzebuje soli do wygenerowania klucza szyfrującego, aby zaszyfrować dane. Wiem, że przechowywanie soli na twardo (zaciemnione) w aplikacji desktopowej nie jest dobrym pomysłem.

Jeśli zdalny serwer nigdy nie może znać hasła użytkownika, to czy jest możliwe, aby użytkownik za każdym razem używał innej soli? Jeśli użytkownik korzysta z aplikacja desktopowa na innym komputerze, w jaki sposób będzie w stanie odszyfrować dane na zdalnym serwerze, jeśli nie ma klucza (nie jest on zakodowany na twardo w oprogramowaniu) ?