Uwaga: ta odpowiedź została napisana w 2013 r. W następnych latach wiele się zmieniło, co oznacza, że ​​należy ją postrzegać przede wszystkim jako sposób, w jaki stosowano najlepsze praktyki 2013.

Teoria

Musimy haszować hasła jako drugą linię obrony. Serwer, który może uwierzytelniać użytkowników, z konieczności zawiera gdzieś w swoich wnętrznościach pewne dane, które mogą być użyte do sprawdzenia hasła. Bardzo prosty system po prostu przechowałby same hasła, a walidacja byłaby prostym porównaniem. Ale jeśli wrogi outsider miałby w prosty sposób rzucić okiem na zawartość pliku lub tabeli bazy danych, która zawiera hasła, wówczas atakujący wiele by się nauczył. Niestety, takie częściowe naruszenia tylko do odczytu zdarzają się w praktyce (zgubiona taśma z kopią zapasową, wycofany, ale nie wyczyszczony dysk twardy, następstwo ataku SQL injection - możliwości jest wiele). Zobacz ten post na blogu, aby zapoznać się ze szczegółową dyskusją.

Ponieważ ogólna zawartość serwera, który może weryfikować hasła, jest koniecznie wystarczająca do tego, by rzeczywiście sprawdzać hasła, osoba atakująca, która uzyskała plik tylko do odczytu migawka serwera jest w stanie wykonać atak słownikowy offline: próbuje potencjalnych haseł, dopóki nie zostanie znalezione dopasowanie. To jest nieuniknione. Dlatego chcemy, aby ten rodzaj ataku był tak trudny, jak to tylko możliwe. Nasze narzędzia są następujące:

• Kryptograficzne funkcje skrótu : są to fascynujące obiekty matematyczne, które każdy może skutecznie obliczyć, a mimo to nikt nie wie, jak je odwrócić. Wygląda to dobrze na nasz problem - serwer mógł przechowywać hash hasła; po przedstawieniu domniemanego hasła serwer musi je po prostu zaszyfrować, aby sprawdzić, czy ma taką samą wartość; a jednak znajomość skrótu nie ujawnia samego hasła.

• Salts : jedną z zalet atakującego nad obrońcą jest równoległość . Atakujący zwykle przechwytuje całą listę zaszyfrowanych haseł i jest zainteresowany złamaniem jak największej ich liczby. Może próbować zaatakować kilka równolegle. Na przykład osoba atakująca może rozważyć jedno potencjalne hasło, zaszyfrować je, a następnie porównać wartość ze 100 zaszyfrowanymi hasłami; oznacza to, że atakujący dzieli koszt mieszania kilku zaatakowanych haseł. Podobna optymalizacja to wstępnie obliczone tabele , w tym tabele tęczowe; jest to nadal paralelizm, ze zmianą współrzędnych w czasie i przestrzeni.

  Wspólną cechą wszystkich ataków wykorzystujących paralelizm jest to, że działają one na kilku hasłach, które zostały przetworzone przez dokładnie tę samą funkcję skrótu . W Salting chodzi o używanie nie jednej funkcji skrótu, ale wielu różnych funkcji skrótu ; Idealnie byłoby, gdyby każde wystąpienie mieszania haseł korzystało z własnej funkcji skrótu. sól to sposób na wybranie określonej funkcji skrótu z dużej rodziny funkcji skrótu. Prawidłowo zastosowane sole całkowicie udaremnią równoległe ataki (w tym tęczowe tablice).

• Powolność : komputery stają się szybsze z czasem (Gordon Moore, współzałożyciel Intel sformułował teorię w swoim słynnym prawie). Ludzkie mózgi nie. Oznacza to, że atakujący mogą „wypróbowywać” coraz więcej potencjalnych haseł wraz z upływem lat, podczas gdy użytkownicy nie mogą zapamiętać coraz bardziej złożonych haseł (lub wręcz odmawiają). Aby przeciwdziałać temu trendowi, możemy uczynić haszowanie z natury powolnym , definiując funkcję haszującą tak, aby używała wielu wewnętrznych iteracji (tysiące, być może miliony).

Mamy kilka standardowych kryptograficznych funkcji skrótu; najbardziej znane to MD5 i rodzina SHA. Zbudowanie bezpiecznej funkcji skrótu z podstawowych operacji nie jest łatwe. Kiedy kryptolodzy chcą to zrobić, myślą intensywnie, a potem intensywniej, i organizują turniej, w którym funkcje zaciekle walczą ze sobą. Kiedy setki kryptografów przez kilka lat gryzło, skrobało i dziurkowało jakąś funkcję i nie znalazło nic złego do powiedzenia na jej temat, zaczynają przyznawać, że być może tę konkretną funkcję można uznać za mniej lub bardziej bezpieczną. To właśnie wydarzyło się w konkursie SHA-3. Musimy użyć tego sposobu projektowania funkcji skrótu, ponieważ nie znamy lepszego sposobu. Matematycznie nie wiemy, czy rzeczywiście istnieją bezpieczne funkcje skrótu; mamy tylko „kandydatów” (na tym polega różnica między „nie można tego zepsuć” a „nikt na świecie nie wie, jak to złamać”).

Podstawowa funkcja skrótu, nawet jeśli jest bezpieczna jako funkcja haszująca nie jest odpowiednia do haszowania haseł, ponieważ:

• jest niesolona, ​​co pozwala na równoległe ataki ( tablice tęczowe dla MD5 lub SHA-1 można uzyskać za darmo, nie trzeba nawet przeliczać ich samodzielnie);
• jest o wiele za szybki i przyspiesza wraz z postępem technologicznym. W przypadku niedawnego procesora graficznego (czyli gotowego produktu konsumenckiego, który każdy może kupić), szybkość mieszania jest liczona jako miliardy haseł na sekundę.

Więc potrzebuję czegoś lepszego. Tak się składa, że ​​połączenie funkcji skrótu i ​​soli oraz jej iteracja nie jest łatwiejsze niż zaprojektowanie funkcji skrótu - przynajmniej jeśli chcesz, aby wynik był bezpieczny. Tam znowu musisz polegać na standardowych konstrukcjach, które przetrwały ciągłe ataki weryfikujących kryptografów.

Dobre funkcje haszujące hasła

PBKDF2

PBKDF2 pochodzi z PKCS # 5. Jest sparametryzowany liczbą iteracji (liczba całkowita, co najmniej 1, bez górnej granicy), solą (dowolna sekwencja bajtów, bez ograniczenia długości), wymaganą długością wyjściową (PBKDF2 może generować wyjście o konfigurowalnej długości), oraz „bazowy PRF”. W praktyce PBKDF2 jest zawsze używany z HMAC, który sam w sobie jest konstrukcją zbudowaną na bazowej funkcji skrótu. Więc kiedy mówimy „PBKDF2 z SHA-1”, w rzeczywistości mamy na myśli „PBKDF2 z HMAC z SHA-1”.

Zalety PBKDF2:

• Został określony dla od dawna, wydaje się na razie nietknięty.
• Jest już zaimplementowany w różnych frameworkach (np. jest dostarczany z .NET).
• Wysoce konfigurowalny (chociaż niektóre implementacje nie pozwalają na wybranie funkcji skrótu, np. ta w .NET jest tylko dla SHA-1).
• Otrzymano błogosławieństwa NIST (modulo różnica między hashowaniem a kluczem derywacja; patrz później).
• Konfigurowalna długość wyjściowa (ponownie, zobacz później).

Wady PBKDF2:

• Obciąża tylko procesor, więc podlega wysokiej optymalizacji za pomocą GPU (obrońca jest podstawowym serwerem, który robi ogólne rzeczy, np. Komputer PC, ale atakujący może wydać swój budżet na bardziej wyspecjalizowany sprzęt, co da mu przewagę).
• Nadal musisz samodzielnie zarządzać parametrami (wytwarzanie i przechowywanie soli, kodowanie liczby iteracji ...). Istnieje standardowe kodowanie parametrów PBKDF2, ale używa ASN.1, więc większość ludzi unika go, jeśli będzie to możliwe (ASN.1 może być trudny w obsłudze dla nie-ekspertów).

bcrypt

bcrypt został zaprojektowany przez ponowne użycie i rozszerzenie elementów szyfru blokowego o nazwie Blowfish. Liczba iteracji to potęga dwójki, która jest odrobinę mniej konfigurowalna niż PBKDF2, ale mimo to wystarczająca. To jest główny mechanizm mieszania haseł w systemie operacyjnym OpenBSD.

Zalety bcrypt:

• Wiele dostępnych implementacji w różnych językach (patrz linki na końcu strony Wikipedii).
• Bardziej odporny na GPU; wynika to ze szczegółów jego wewnętrznej konstrukcji. Autorzy bcrypt zrobili to tak dobrowolnie: ponownie wykorzystali Blowfish, ponieważ Blowfish był oparty na wewnętrznej tabeli RAM, która jest stale dostępna i modyfikowana podczas przetwarzania. To znacznie utrudnia życie każdemu, kto chce przyspieszyć bcrypt za pomocą GPU (GPU nie są dobre w robieniu wielu równoległych dostępów do pamięci). Zobacz tutaj, aby zapoznać się z omówieniem.
• Standardowe kodowanie wyjścia, które obejmuje sól, liczbę iteracji i wyjście jako jeden prosty do przechowywania ciąg znaków drukowalnych znaków.

Wady bcrypt:

• Rozmiar wyjściowy jest stały: 192 bity.
• Chociaż bcrypt dobrze radzi sobie z działaniem GPU, nadal można go dokładnie zoptymalizować FPGA: nowoczesne układy FPGA mają wiele małych wbudowanych bloków pamięci RAM, które są bardzo wygodne do równoległego uruchamiania wielu implementacji bcrypt w jednym układzie. Zrobione.
• Długość wejściowego hasła jest ograniczona do 51 znaków. Aby obsługiwać dłuższe hasła, należy połączyć bcrypt z funkcją haszującą (należy zaszyfrować hasło, a następnie użyć wartości hash jako „hasła” dla bcrypt). Wiadomo, że łączenie prymitywów kryptograficznych jest niebezpieczne (patrz wyżej), więc takie gry nie mogą być ogólnie zalecane.

scrypt

scrypt to znacznie nowsza konstrukcja (zaprojektowana w 2009 roku), która opiera się na PBKDF2 i szyfrze strumieniowym o nazwie Salsa20 / 8, ale to tylko narzędzia skupiające się na sile rdzenia of scrypt, czyli RAM . scrypt został zaprojektowany tak, aby z natury korzystał z dużej ilości pamięci RAM (generuje kilka pseudolosowych bajtów, a następnie wielokrotnie je odczytuje w pseudolosowej sekwencji). „Dużo pamięci RAM” to coś, co jest trudne do porównania. Podstawowy komputer dobrze radzi sobie z dostępem do pamięci RAM i nie będzie próbował jednocześnie odczytywać dziesiątek niepowiązanych bajtów pamięci RAM. Atakujący z GPU lub FPGA będzie chciał to zrobić i będzie to trudne.

Zalety scrypt:

• PC, czyli dokładnie to, co obrońca będzie używany podczas haszowania haseł, jest najbardziej wydajną platformą (lub wystarczająco blisko) do obliczania scryptów. Atakujący nie otrzymuje już premii, wydając swoje pieniądze na GPU lub FPGA.
• Jeszcze jeden sposób dostrojenia funkcji: rozmiar pamięci.

Wady skryptu:

• Jeszcze nowe (moja własna zasada to czekać co najmniej 5 lat ogólnej ekspozycji, więc nie ma szyfru produkcji do 2014 roku - ale oczywiście najlepiej, jeśli inne osoby spróbuj scrypt w środowisku produkcyjnym, ponieważ daje to dodatkową ekspozycję).
• Mało dostępnych, gotowych do użycia implementacji dla różnych języków.
• Nie wiadomo, czy procesor / Miks RAM jest optymalny. Dla każdego pseudolosowego dostępu do pamięci RAM scrypt nadal oblicza funkcję skrótu. Brak pamięci podręcznej wyniesie około 200 cykli zegara, jedno wywołanie SHA-256 jest bliskie 1000. W tym miejscu może być miejsce na ulepszenia.
• Jeszcze jeden parametr do skonfigurowania: rozmiar pamięci.

Iterowane i solone OpenPGP S2K

Cytuję ten, ponieważ użyjesz go, jeśli używasz szyfrowania plików opartego na hasłach za pomocą GnuPG. To narzędzie jest zgodne z formatem OpenPGP, który definiuje własne funkcje haszowania haseł, zwane „Simple S2K”, „Salted S2K” oraz „ Iterated and Salted S2K”. Jedynie trzecią można uznać za „dobrą” w kontekście tej odpowiedzi. Jest definiowany jako skrót bardzo długiego ciągu (konfigurowalnego, do około 65 MB) składającego się z powtórzenia 8-bajtowej soli i hasła.

Jeśli chodzi o te rzeczy, Iteracja OpenPGP A solone S2K jest przyzwoite; można go uznać za podobny do PBKDF2, z mniejszą konfigurowalnością. Bardzo rzadko można go spotkać poza OpenPGP, jako samodzielną funkcję.

Unix „crypt”

Najnowsze systemy uniksopodobne (np. Linux) do sprawdzania haseł użytkowników, używaj iterowanych i solonych wariantów funkcji crypt () w oparciu o dobre funkcje mieszające, z tysiącami iteracji. To jest całkiem dobre. Niektóre systemy mogą również używać bcrypt, co jest lepsze.

Stara funkcja crypt (), oparta na szyfrze blokowym DES, nie jest wystarczająco dobra :

• Jest powolny w oprogramowaniu, ale szybki w sprzęcie i może być również szybki w oprogramowaniu, ale tylko podczas obliczania kilku instancji równolegle (technika znana jako SWAR lub „bitslicing”). Dlatego atakujący ma przewagę.
• Nadal jest dość szybki, tylko z 25 iteracjami.
• Ma sól 12-bitową, co oznacza, że ​​ponowne użycie soli będzie dość często.
• Obcina hasła do 8 znaków (znaki poza ósmym są ignorowane), a także upuszcza górny bit każdego znaku (więc utknąłeś mniej więcej w ASCII).

Ale nowsze warianty, które są domyślnie aktywne, będą w porządku.

Funkcje haszujące złe hasła

O wszystkim innym , w szczególności praktycznie każdą metodę domowej roboty, którą ludzie nieustannie wymyślają.

Z jakiegoś powodu wielu programistów nalega na samodzielne projektowanie funkcji i wydaje się zakładać, że „bezpieczny projekt kryptograficzny” oznacza „łączenie wszystkich operacji kryptograficznych lub niekryptograficznych, o których można pomyśleć”. Zobacz przykład to pytanie. Wydaje się, że podstawową zasadą jest to, że sama złożoność wynikającego z tego kompletnie zagmatwanego bałaganu instrukcji będzie zamętem dla napastników. W praktyce jednak sam programista będzie bardziej zdezorientowany swoim własnym dziełem niż atakujący.

Złożoność jest zła. Domowe jest złe. Nowe jest złe. Jeśli to pamiętasz, unikniesz 99% problemów związanych z haszowaniem haseł, kryptografią, a nawet ogólnie bezpieczeństwem.

Haszowanie haseł w systemach operacyjnych Windows, które kiedyś być oszałamiająco okropne, a teraz jest po prostu okropne (niesolone, nie iterowane MD4).

Wyprowadzanie kluczy

Do teraz , rozważaliśmy kwestię haszowania haseł . Bliski problem polega na przekształceniu hasła w klucz symetryczny, którego można użyć do szyfrowania; nazywa się to wyprowadzaniem klucza i jest pierwszą rzeczą, którą robisz, kiedy „zaszyfrujesz plik hasłem”.

Możliwe jest stworzenie wymyślnych przykładów funkcji mieszania haseł, które są bezpieczne, jeśli chodzi o przechowywanie tokena do weryfikacji hasła, ale straszne, jeśli chodzi o generowanie kluczy symetrycznych; i odwrotnie jest równie możliwe. Ale te przykłady są bardzo „sztuczne”. Dla praktycznych funkcji, takich jak ta opisana powyżej:

• Wynik funkcji haszującej hasło jest akceptowalny jako klucz symetryczny, po ewentualnym obcięciu do wymaganego rozmiaru.
• Funkcja wyprowadzania klucza może służyć jako funkcja haszująca hasło, o ile „klucz pochodny” jest wystarczająco długi, aby uniknąć „generycznych preimage” (napastnik ma po prostu szczęście i znajduje hasło, które daje takie same wyniki). Wyjście o długości większej niż 100 bitów wystarczy.

Rzeczywiście, PBKDF2 i scrypt są KDF, a nie funkcją haszowania haseł - a NIST "zatwierdza" PBKDF2 jako KDF, a nie jawnie jako haszer hasła (ale jest możliwe, przy bardzo niewielkiej ilości hipokryzji, przeczytaj prozę NIST w taki sposób, że wydaje się mówić, że PBKDF2 jest dobre do haszowania haseł).

Odwrotnie, bcrypt jest tak naprawdę szyfrem blokowym (większość przetwarzania haseł jest „harmonogramem kluczy”), który jest następnie używany w trybie CTR do utworzenia trzech bloków (tj. 192 bitów) pseudolosowego wyniku, co czyni go rodzajem funkcji skrótu. bcrypt można przekształcić w KDF za pomocą niewielkiej operacji, używając szyfru blokowego w trybie CTR dla większej liczby bloków. Ale jak zwykle nie możemy polecić takich domowych transformacji. Na szczęście 192 bity są już więcej niż wystarczające do większości zastosowań (np. Szyfrowanie symetryczne za pomocą GCM lub EAX wymaga tylko 128-bitowego klucza).

Różne tematy

Ile iteracji?

Jak najwięcej! To solone i powolne haszowanie to wyścig zbrojeń między napastnikiem a obrońcą. Używasz wielu iteracji, aby haszowanie hasła było trudniejsze dla wszystkich . Aby zwiększyć bezpieczeństwo, należy ustawić tę liczbę na możliwie najwyższym poziomie na serwerze, biorąc pod uwagę zadania, które w innym przypadku musi wykonać serwer. Wyższe jest lepsze.

Kolizje i MD5

MD5 jest zepsute : obliczeniowo łatwo jest znaleźć wiele par odrębnych danych wejściowych, które haszują do tego samego wartość. Nazywa się to kolizjami .

Jednak kolizje nie są problemem przy mieszaniu haseł . Haszowanie haseł wymaga, aby funkcja skrótu była odporna na preobrazki , a nie na kolizje. Kolizje polegają na znajdowaniu par wiadomości, które dają te same dane wyjściowe bez ograniczeń , podczas gdy podczas mieszania hasła atakujący musi znaleźć wiadomość, która daje dane dane wyjściowe, których atakujący nie otrzymuje wybierać. To jest zupełnie inne. O ile nam wiadomo, MD5 jest nadal (prawie) tak silna, jak kiedykolwiek w odniesieniu do przedobrazów (istnieje teoretyczny atak, który jest nadal bardzo absurdalnie niemożliwy do wykonania w praktyce) .

Prawdziwy problem z MD5, ponieważ jest powszechnie używany w haszowaniu haseł, polega na tym, że jest bardzo szybki i niesolony. Jednak PBKDF2 używany z MD5 byłby solidny. Nadal powinieneś używać SHA-1 lub SHA-256 z PBKDF2, ale do public relations. Ludzie denerwują się, gdy słyszą „MD5”.

Wytwarzanie soli

Głównym i jedynym celem soli jest bycie tak wyjątkowym , jak to tylko możliwe. Ilekroć wartość soli jest ponownie wykorzystywana gdziekolwiek , może to pomóc atakującemu.

Na przykład, jeśli użyjesz nazwy użytkownika jako soli, atakujący (lub kilku atakujących w zmowie) może uznać, że warto zbudować tęczowe tablice, które atakują funkcję mieszania haseł, gdy sól jest „ admin ”(lub„ root ”lub„ joe ”), ponieważ będzie kilka, prawdopodobnie wiele witryn na całym świecie, które będą miały użytkownika o nazwie„ admin ”. Podobnie, gdy użytkownik zmienia swoje hasło, zwykle zachowuje swoje imię i nazwisko, co prowadzi do ponownego użycia soli. Stare hasła są cennymi celami, ponieważ użytkownicy mają zwyczaj ponownego wykorzystywania haseł w kilku miejscach (co jest znane jako zły pomysł i jako takie są reklamowane, ale mimo to zrobią to, ponieważ ułatwia im to życie), a także dlatego, że ludzie mają tendencję do generowanie haseł „w kolejności”: jeśli dowiesz się, że stare hasło Boba to „SuperSecretPassword37”, wówczas bieżącym hasłem Boba jest prawdopodobnie „SuperSecretPassword38” lub „SuperSecretPassword39”.

Tanim sposobem uzyskania niepowtarzalności jest użycie losowości . Jeśli generujesz sól jako sekwencję losowych bajtów z zabezpieczonego kryptograficznie PRNG, który oferuje Twój system operacyjny ( / dev / urandom , CryptGenRandom () ...) wtedy uzyskasz wartości soli, które będą „unikalne z dostatecznie dużym prawdopodobieństwem”. 16 bajtów wystarczy, abyś nigdy nie zobaczył kolizji soli w swoim życiu, co jest przesadą, ale dość proste.

UUID to standardowy sposób generowania „unikalnych” wartości. Zauważ, że UUID „wersji 4” używa po prostu losowości (122 losowych bitów), jak wyjaśniono powyżej. Wiele frameworków programistycznych oferuje proste w użyciu funkcje do generowania UUID na żądanie i mogą być używane jako sole.

Salt Secrecy

Sole nie mają być tajemnicą; w przeciwnym razie nazwalibyśmy je kluczami . Nie musisz upubliczniać soli, ale jeśli musisz je upublicznić (np. W celu obsługi haszowania po stronie klienta), nie przejmuj się tym zbytnio. Sole są dla wyjątkowości. Ściśle mówiąc, sól to nic innego jak wybór określonej funkcji skrótu w ramach dużej rodziny funkcji.

„Pieprz”

Kryptografowie nigdy nie mogą pozwolić sobie na samą metaforę; muszą rozszerzyć to o dalsze analogie i złe kalambury. „Przyprawianie” polega na użyciu sekretnej soli, czyli klucza. Jeśli używasz „pieprzu” w funkcji mieszania hasła, to przełączasz się na zupełnie inny rodzaj algorytmu kryptograficznego; mianowicie, na podstawie hasła obliczasz kod uwierzytelniania wiadomości. Klucz MAC to Twój „pieprz”.

Doping ma sens, jeśli możesz mieć tajny klucz, którego atakujący nie będzie mógł odczytać. Pamiętaj, że używamy haszowania haseł, ponieważ uważamy, że osoba atakująca może przechwycić kopię bazy danych serwera lub być może całego dysku serwera. Typowy scenariusz to serwer z dwoma dyskami w RAID 1. Jeden dysk nie działa (frytki na płycie elektronicznej - to się często zdarza). Administrator systemu zastępuje dysk, lustro jest odbudowywane, żadne dane nie są tracone z powodu magii RAID 1. Ponieważ stary dysk nie działa, administrator systemu nie może łatwo wyczyścić jego zawartości. Po prostu odrzuca dysk. Atakujący przeszukuje worki na śmieci, wyjmuje dysk, wymienia tablicę i oto! Ma pełny obraz całego systemu serwerowego, w tym bazę danych, pliki konfiguracyjne, pliki binarne, system operacyjny ... pełne pieniądze, jak mówią Brytyjczycy. Aby pieprz był naprawdę przydatny, musisz być w specjalnej konfiguracji, w której jest coś więcej niż komputer z dyskami; potrzebujesz HSM. HSM są bardzo drogie, zarówno jeśli chodzi o sprzęt, jak i procedury operacyjne. Ale z HSM możesz po prostu użyć tajnego „pieprzu” i przetwarzać hasła za pomocą prostego HMAC (np. SHA-1 lub SHA-256). Będzie to znacznie bardziej wydajne niż bcrypt / PBKDF2 / scrypt i ich uciążliwe iteracje. Ponadto użycie HSM będzie wyglądać niezwykle profesjonalnie podczas wykonywania audytu zaufania internetowego.

Haszowanie po stronie klienta

Ponieważ haszowanie jest (celowo) drogie, w sytuacji klient-serwer może mieć sens wykorzystanie procesora podłączonych klientów. W końcu, kiedy 100 klientów łączy się z pojedynczym serwerem, klienci łącznie mają o wiele więcej siły niż serwer.

Aby wykonać haszowanie po stronie klienta, protokół komunikacyjny musi zostać ulepszony, aby obsługiwał wysyłanie soli z powrotem do klienta. Oznacza to dodatkową podróż w obie strony w porównaniu z prostym protokołem wysyłania hasła przez klienta do serwera. Może to być łatwe do dodania do konkretnego przypadku, ale nie musi.

Haszowanie po stronie klienta jest trudne w kontekście sieci Web, ponieważ klient używa JavaScript, co jest dość anemiczne w przypadku zadań intensywnie wykorzystujących procesor.

W kontekście SRP, hasło haszowanie musi koniecznie występować po stronie klienta.

Wniosek

Użyj bcrypt. PBKDF2 też nie jest zły. Jeśli użyjesz scrypt, będziesz „nieco wczesnym użytkownikiem” z ryzykiem, które jest implikowane przez to wyrażenie; ale byłby to dobry ruch dla postępu naukowego („manekin awaryjny” to bardzo honorowy zawód).

Do przechowywania skrótów haseł potrzebny jest algorytm na tyle wolny, aby ataki siłowe były niewykonalne. Solenie hasła pomoże w walce z tęczowymi atakami, ale nie w przypadku ataków siłowych. Aby przechowywać skróty haseł, musisz użyć algorytmu specjalnie zaprojektowanego do tego celu; takie jak:

• bcrypt
• PBKDF2
• scrypt

scrypt jest nowy, ale interesujący, ponieważ wykorzystuje nie tylko zmienny współczynnik pracy , ale także trudny w pamięci funkcje em>. To dramatycznie zwiększa koszt ataków siłowych, ponieważ zwiększa się zarówno czas działania, jak i wymagania dotyczące pamięci.

Hasła przechowywane w bazie danych jako zaszyfrowane wartości mogą być odzyskane albo poprzez obliczenie siłowych haszów albo poprzez użycie tabel tęczowych (które są specyficzne dla używanego algorytmu).

Tęczowa tablica to utworzony jako seria wstępnie obliczonych wartości dla pliku słownika lub częściej każda kombinacja danego zestawu znaków [az, AZ, 0-9] jest typowym przykładem.

Zasadniczo mogą one przyspieszyć złamanie hasła przez umożliwienie wyszukania wartości skrótu w tabeli zamiast wymagania od atakującego utworzenia skrótu dla każdego hasła. Tęczowe tabele dla popularnych algorytmów haseł (np. NTLM, MD5 itp.) Można znaleźć w Internecie, dzięki czemu dostęp do dużych ich ilości jest dość prosty.

Istnieje wiele sposobów na poprawę bezpieczeństwa haszów przechowywanych w bazie danych.

Najpierw należy użyć wartości soli na użytkownika, wartość ta jest przechowywana w bazie danych wraz z zaszyfrowanym hasłem. Nie ma być tajne, ale służy do spowolnienia procesu brutalnej siły i uczynienia tabel tęczowych niepraktycznymi w użyciu.

Kolejnym dodatkiem, który widziałem, jest dodanie czegoś, co nazywano wartością pieprzową. To był tylko kolejny losowy ciąg, ale taki sam dla wszystkich użytkowników i przechowywany z kodem aplikacji, a nie w bazie danych. Teoria jest taka, że ​​w pewnych okolicznościach baza danych może zostać naruszona, ale kod aplikacji nie, iw takich przypadkach może to poprawić bezpieczeństwo. Powoduje to jednak problemy, jeśli wiele aplikacji korzysta z tej samej bazy danych haseł.

Trzecim sposobem poprawy bezpieczeństwa haseł jest użycie funkcji wolnego hasła, która nie będzie miała ogromny wpływ na poszczególnych użytkowników, ale znacznie spowolni atakującego w łamaniu haseł pobranych z bazy danych. Więcej informacji na temat tego podejścia można znaleźć tutaj

Aktualizacja 4 : do 2016 r. ulepszenia sprzętu i inne czynniki spowodowały wzrost szybkości mieszania bitcoinów o ponad 100 000 (!) w ciągu 5 lat od pierwszego napisania tego posta w 2011 roku. Techniki łamania haseł również uległy poprawie od strony oprogramowania. Dlatego użytkownicy powinni dodać kilka dodatkowych znaków do minimalnej długości swoich haseł, a liczba iteracji musi zostać zwiększona, a my wszyscy naprawdę musimy się przygotować do przejścia na lepsze algorytmy, takie jak Argon2.

Aktualizacja 3 : w 2015 r. w konkursie haszowania haseł wyłoniono zwycięzcę: Argon2. Został zaprojektowany jako „trudny w pamięci”, aby utrudnić implementacje GPU przez crackerów; prosty; wysoce konfigurowalny; odporny na wycieki z kanału bocznego itp. Jeśli przejdzie próbę czasu, może to być znaczący krok naprzód, ale jak zauważył Thomas w Czy istnieją bardziej nowoczesne metody haszowania haseł niż bcrypt i scrypt?, powinieneś uważać na nowe, lśniące algorytmy i prawdopodobnie dać profesjonalistom więcej czasu na szukanie słabych punktów.

Aktualizacja 2 : w 2013 roku kilku ekspertów zainicjowało konkurs na haszowanie haseł, który powinien zaowocować ulepszonymi i bardziej użytecznymi metodami. Zwycięzcy zostaną wybrani do 2015 r. Doskonałe informacje na temat takiej potrzeby, a także dobre rady w międzyczasie, można znaleźć na stronie Bezpieczeństwo hasłem: przeszłe, obecne, przyszłe od Hasła ^ 12. Należy pamiętać, że pojawienie się szybszego i szybszego sprzętu (jak omówiono poniżej) implikuje potrzebę stosowania algorytmów intensywnie korzystających z pamięci, takich jak scrypt, i że bcrypt jest również nadal odporny na ataki GPU w przeciwieństwie do PBKDF2 lub crypt.

Inni tutaj zwrócili uwagę, że ataki brutalnej siły muszą być chronione za pomocą soli, mimo że MYSQL wciąż tego nie odkrył. Odnotowano również znaczenie iteracji i było znane od przełomowego artykułu na temat krypty uniksowej w 1978 roku autorstwa Roberta Morrisa i Kena Thompsona. Ale wielu ludzi (i deweloperów także, jak Django!) Najwyraźniej nadal uważa, że ​​brutalna siła musi zająć dość dużo czasu lub być dość droga, a zatem uważa, że ​​pojedyncza iteracja SHA-1 jest odpowiednia do haszowania haseł.

Nieprawda! Prawo Moore'a i przetwarzanie w chmurze nas dogoniły. Złamanie skrótu SHA-1 hasła alfanumerycznego o długości 8 ((26 + 26 + 10) ^ 8 = 62 ^ 8 = 218340,105,584,896 = 218 bilionów kombinacji) na nowoczesnym komputerze stacjonarnym zajmuje 5 dni lub 1 godzinę w przypadku wypożyczenia kilka węzłów obliczeniowych Amazon ( Ile czasu zajmuje faktyczne wygenerowanie tabel tęczowych? - Bezpieczeństwo IT)

Aktualizacja: pojemność haszowania bitcoinów

Najpotężniejszą zorganizowaną funkcją haszowania na świecie (z wyłączeniem możliwych tajnych systemów) jest bitcoin sieć wydobywcza. [Od maja 2011 r. Było] wykonywanie skrótów SHA-256 z łączną szybkością ponad 11 Thash / s, tj. 11 * 10 ^ 12 hash / s ( do 2016 r. To było 1700000 Thash / s - patrz aktualizacja 4 powyżej ), a kurs ostatnio szybko rośnie ( wykresy). Górnicy pracują, aby zarobić szacunkowo 700 000 USD tygodniowo, które daje wydobycie przy obecnej cenie 14 USD za bitcoin (BTC) ( wykres) i szybkości 50 BTC produkowanych co 10 minut. Popularny obecnie sprzęt obejmuje procesor graficzny Radeon HD 5970, z których każdy ma łącznie 3200 procesorów strumieniowych i może wykonać około 800 Mhash / s. Jest również oszczędny w zużyciu energii na poziomie około 2,3 Mhash / Joule. Zobacz Porównanie sprzętu do wydobywania bitcoinów, aby uzyskać dużo więcej opcji. Okazuje się, że węzły GPU na EC2 firmy Amazon używają procesorów graficznych Nvidia Tesla, które są mniej wydajne w haszowaniu, a ich węzły nie są opłacalne do wydobywania po dzisiejszych cenach.

To około dwa razy więcej niż jeden 5,5 Thash / s szacunkowej mocy mieszającej 500 najlepszych superkomputerów na świecie łącznie, chociaż oczywiście superkomputery były zwykle projektowane pod kątem wydajności zmiennoprzecinkowej, a nie haszowania.

Jako prąd ekstremalny przypadku, jeśli ta zdolność haszowania została przekierowana na próbę złamania haseł, np po załamaniu cen bitcoinów byłoby to przerażające w stosunku do algorytmów haseł bez iteracji. Hasła 8-znakowe przy użyciu całkowicie losowego zestawu wszystkich 94 drukowanych znaków wypadałyby w mniej niż 10 minut (94 ^ 8 / (11 * 10 ^ 12 * 60) = 9,2). Hasła zawierające 10 znaków zajęłyby mniej niż 57 dni (94 ^ 10 / (11 * 10 ^ 12 * 3600 * 24) = 56,7). 10-znakowe hasła alfanumeryczne z dużymi i małymi literami (26 + 26 + 10 = 62 możliwe znaki) zajęłyby mniej niż jeden dzień (62 ^ 10 / (11 * 10 ^ 12 * 3600 * 24) = 0,88), nawet jeśli byłyby dobrze zrandomizowane.

Ale jeśli programiści używali po prostu np. liczba iteracji wynosząca 2000, jak sugeruje Thomas, dobre 10-znakowe hasła przetrwałyby lata. Chociaż 8-znakowe hasła można by łatwo złamać, w ciągu 13 dni (2000 * 94 ^ 8/11 10 ^ 12/3600/24 ​​= 12,8 dni).

Zobacz też:

• Problemy ze złymi algorytmami przy Brute force vs inne metody odzyskiwania haseł z pliku shadow - bezpieczeństwo IT
• Jak chronić się przed brutalnym wymuszeniem na poziom aplikacji / serwera

Hasło musi być zawsze zaszyfrowane, ale nie oznacza to, że nie ma możliwości ataków z użyciem siły. Należy zastosować dodatkowe środki dotyczące przechowywania i zarządzania hasłami użytkowników. Gorąco polecam ten artykuł od Solar Designer na ten temat: http://php-security.org/2010/05/26/mops-submission-10-how-to-manage-a-php-applications-users -and-passwords / index.html.

Hasła należy zawsze solić i rozciągać przed ich przechowywaniem. Zasadniczo polega to na dołączeniu lub poprzedzeniu jakiegoś tekstu do hasła i kilkukrotnym zahaszowaniu wyniku. Jeśli chodzi o algorytmy hashujące, obecnie zalecane jest wszystko inne niż MD5 i SHA-1 - przejdź do SHA 256 lub 512 (patrz http://www.schneier.com/blog/archives/2009/06/ever_better_cry.html)

Dobry algorytm haszowania haseł musi mieć sól i coś, co sprawi, że obliczenie hasła będzie kosztowne (zwykle liczba iteracji).

Najlepszą i najpowszechniejszą metodą jest PBKDF2. Chociaż nie jest doskonały, powinien być punktem odniesienia dla wszystkich:

http://en.wikipedia.org/wiki/PBKDF2

Popieram zalecenia dotyczące PBKDF2. Nie jest to najbardziej kosztowne obliczeniowo, ale ma precyzyjny standard odniesienia podczas implementacji i jest dobrze akceptowane.

https://tools.ietf.org/html/rfc2898

Naprawdę polecam jednak przeczytanie artykułu Colina Percivala o scrypt. Wykonuje dobrą robotę, opisując występujące tutaj problemy. Domyślam się, że scrypt będzie z czasem wyglądał coraz lepiej.

http://www.tarsnap.com/scrypt.html

Posiadanie możliwego do wdrożenia standardu to nie jest nic, nawiasem mówiąc - istnieją różnice między algorytmami opisanymi w artykułach a implementacjami referencyjnymi zarówno w bcrypt, jak i scrypt, jeśli pamięć służy.

W zależności od algorytmu, którego użyjesz, odpowiedź prawdopodobnie brzmi nie.

Po pierwsze, powinieneś je posortować, oznacza to po prostu dodanie lub dodanie tekstu do hasła.

Następnie powinien używać silnego algorytmu (md5 tego nie działa)

Warto zauważyć, że chociaż bcrypt i scrypt są dobrymi rozwiązaniami dla haseł, z korzyścią dla tego ostatniego, scrypt wydaje się być podatny na ataki związane z synchronizacją pamięci podręcznej. Jak zasugerowano tutaj: http://eprint.iacr.org/2013/525 Catena będzie przed tym bezpieczna, wraz z możliwymi do udowodnienia bezpieczeństwem i kilkoma innymi fajnymi funkcjami.

Mówi się, że bcrypt działa wolniej na procesorach graficznych, co powoduje wolniejsze forsowanie brutalności. Jednak przy stale rozwijającym się sprzęcie komputerowym nie powinniśmy polegać tylko na trudności z zaimplementowaniem określonego algorytmu mieszającego na określonym sprzęcie.

Zamiast tego można dowolnie zwiększyć koszt brutalnego modyfikowania skrótu za pomocą zmiennej „zmienna współczynnik pracy / kosztu ”(czasami nazywany także„ rundami ”), który obsługują niektóre funkcje skrótu. Wśród nich są bcrypt i SHA-512.

Funkcja crypt () biblioteki Glibc umożliwia określenie rund dla niektórych algorytmów haszujących. Na przykład współczynnik kosztu 100000 dla SHA-512 sprawia, że ​​generowanie (a tym samym brutalne wymuszanie) skrótu jest około 4 razy wolniejsze niż współczynnik kosztu 08 dla bcrypt. Można to potwierdzić za pomocą programu do rozwiązywania skrótów, takiego jak hashcat.

Jeśli zakładasz, że w pewnym momencie skróty i sole hasła zostaną skradzione, a atakujący użyją sprzętu ASIC, aby je złamać, po prostu zwiększ pracy, aby nadal było to dla nich zbyt kosztowne, jednocześnie nie obciążając procesora serwera zwykłym uwierzytelnianiem użytkownika.

Jednak znaczenie długich i losowych haseł ma zastosowanie.

Właśnie napisałem post na blogu dotyczący szczegółów.

tsk tsk, Próba zabezpieczenia systemu przez powolne szyfrowanie to głupiec.

Na przykład, powiedzmy odwrotnie, mamy hash i chcemy aby uzyskać hasło (i sól, jeśli istnieje).

Nawet jeśli mamy wykonywać miliardy haszów na sekundę, potrzebujemy sposobu, aby dopasować wartość .

Na przykład, powiedzmy, że następna wartość:

SALT: IT_ISASALT VALUE: 123456 i jest to hash: 7D371ADDB8862FD3B8320020B0C6B52BEE716A8204CA18B03C9A6B4686EEB610 to

przekształć hash-> SALT + VALUE.

Jednym ze sposobów osiągnięcia tego jest zaszyfrowanie wartości i próba porównania, jeśli część wartości istnieje w jakimś słowniku.

Na przykład , przetestowaliśmy kombinację i znaleźliśmy:

aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d KOŃ („koń” to słowo, które istnieje w naszym słowniku).

Czy to właściwa wartość ?. Nie wiemy, ale może być, więc musimy przechowywać tę kombinację i spróbować z resztą. To powolny proces i wymaga dużej ilości pamięci. Ale nawet jeśli jest to możliwe, mogliśmy znaleźć wiele fałszywych wartości. Moglibyśmy więc zredukować dopasowania z 2 ^ 256 kombinacji do 2 ^ 100 lub więcej kombinacji. W tym celu potrzebujemy sposobu, aby znaleźć prawidłowe dopasowanie. Jeśli SALT nie jest trywialny, to zadanie może zająć dużo czasu i zasobów, a szanse na sukces są nadal niskie.

Teraz, powiedzmy, że moglibyśmy wygenerować nowy hash (na przykład, utworzyć fałszywe konto), więc znamy wartość i skrót (ale sól). Bardzo upraszcza to operację, ponieważ znalezienie dopasowania równa się znalezieniu tekstu, który kończy się naszą wartością (przykład: 123456). Ale co, jeśli sól nie jest generowana jako SÓL + WARTOŚĆ, ale SÓL1 + WARTOŚĆ + SÓL2 lub jeśli SÓL + WARTOŚĆ2, gdzie WARTOŚĆ2 jest wartością zmodyfikowaną przez jakiś nieznany nam algorytm.

Teraz przejdźmy do powiedzmy, że nasz hash jest generowany w następujący sposób:

hash256(SALT+hash256(SALT+VALUE))

• Jeśli SALT jest tajny, nie ma automatycznego sposobu na dopasowanie lub znalezienie oryginalnej wartości.
• Nawet gdybyśmy mieli komputer, który wygenerowałby każdy możliwy hash256 w ciągu sekundy (tak zwane Quantum Komputer), potrzebujemy sposobu, aby dowiedzieć się, która wartość jest dobra, a która nie, i zajmie dużo więcej zasobów.

Podsumowując:

• Szybkość generowania skrótu jest niczym w porównaniu z algorytmem, który sprawdza, czy wygenerowany skrót jest zgodny, czy nie. Możesz spróbować wygenerować 1 milion, 1 miliard lub 1 bilion haszów i nie zmieni to głównego problemu. Musimy znaleźć sposób, aby ustalić, czy jeden (z tych miliardów haszów) jest teraz.
• Nie chodzi o entropię. W tym przypadku entropia to tylko liczba w porównaniu z rzeczywistością.

Używam tutaj SHA1

  def __encrypt (self, plaintext, salt = ""): "" "zwraca SHA1 hexdigest tekstu jawnego i soli" "" fraza = hashlib.sha1 () fraza.update ("% s -% s"% (tekst jawny, sól)) return expression.hexdigest () def set_password (self, new_password): "" "ustawia zaszyfrowane_hasło użytkownika" "" #from data i godzina import data godzina , timedelta import datetime if not self.salt: self.salt = self .__ encrypt (str (datetime.datetime.now ())) self.crypted_password = self .__ encrypt (new_password, self.salt) def check_password (self, Plaintext) : return self .__ encrypt (plaintext, self.salt) == self.crypted_password  

Zamiast solenia haseł w ten sposób chciałbym, aby algorytm został zmieniony tak, aby nie potrzebował soli i nadal nie będzie dwukrotnie haszował tego samego wejścia do tej samej wartości.