Czy SHA-1 jest bezpieczny dla przechowywania haseł?

Question

Czy SHA-1 jest bezpieczny dla przechowywania haseł?

Wniosek: SHA-1 jest tak samo bezpieczny jak wszystko przed atakami preimage, jednak jest łatwy do obliczenia, co oznacza, że łatwiej jest zamontować atak bruteforce lub słownikowy. (To samo dotyczy następców, takich jak SHA-256.) W zależności od okoliczności lepszym wyborem może być funkcja hash, która została zaprojektowana tak, aby była kosztowna obliczeniowo (np. bcrypt).

Niektórzy często rzucają uwagami typu "SHA - 1 jest zepsuty", więc staram się zrozumieć, co dokładnie to znaczy. Załóżmy, że mam bazę hashów haseł SHA - 1, a atakujący z najnowocześniejszym algorytmem łamania SHA-1 i botnetem z 100 000 maszyn dostaje do niego dostęp. (Posiadanie kontroli nad komputerami domowymi 100k oznaczałoby, że mogą wykonywać około 10^15 operacji na sekundę.) Ile czasu potrzebowaliby

znaleźć hasło jednego użytkownika?
znaleźć hasło danego użytkownika?
znaleźć hasło wszystkich użytkowników?
znajdź sposób na Zaloguj się jako jeden z użytkowników?
znaleźć sposób, aby zalogować się jako konkretny użytkownik?

Jak to się zmienia, jeśli hasła są zasolone? Czy metoda solenia (prefiks, postfix, oba, czy coś bardziej skomplikowanego jak xor-ing) ma znaczenie?

Oto moje obecne zrozumienie, po jakimś googlowaniu. Proszę poprawić odpowiedzi, jeśli coś źle zrozumiałam.

Jeśli nie ma soli, atak tęczy natychmiast odnajdzie wszystkie hasła (z wyjątkiem bardzo długich one).
jeśli istnieje wystarczająco długa losowa sól, najskuteczniejszym sposobem na znalezienie haseł jest brutalna siła lub atak słownikowy. Ani ataki kolizyjne, ani preimage nie pomagają w znalezieniu rzeczywistego hasła, więc ataki kryptograficzne przeciwko SHA-1 nie są tutaj pomocne. Nie ma nawet większego znaczenia, jaki algorytm jest używany - można nawet użyć MD5 lub MD4, a hasła byłyby równie bezpieczne (jest niewielka różnica, ponieważ obliczanie skrótu SHA-1 jest wolniejsze).
aby ocenić, jak bezpieczne jest "tak samo bezpieczne", Załóżmy, że pojedyncza operacja sha1 wymaga 1000 operacji, a hasła zawierają wielkie, małe i cyfry (czyli 60 znaków). Oznacza to, że atakujący może przetestować 10¹⁵*60*60*24 / 1000 ~= 10¹⁷ potencjalne hasło dziennie. W przypadku ataku brute force oznaczałoby to przetestowanie wszystkich haseł do 9 znaków w ciągu 3 godzin, do 10 znaków w tygodniu, do 11 znaków w roku. (Zajmuje 60 razy tyle za każdy dodatkowy charakter.) Atak słownikowy jest dużo, dużo szybszy (nawet atakujący z jednym komputerem może go wykonać w kilka godzin), ale znajduje tylko słabe hasła.
aby zalogować się jako użytkownik, atakujący nie musi znać dokładnego hasła; wystarczy znaleźć ciąg znaków, który daje ten sam hash. To się nazywa pierwszy atak preimage. Z tego co wiem, nie ma żadnych preimage ' owych ataków na SHA-1. (Atak bruteforce zajmie 2¹⁶⁰ operacje, czyli nasz teoretyczny napastnik potrzebowałby 10³⁰ lata, żeby to zrobić. Granice możliwości teoretycznych wynoszą ok. 2⁶⁰ operacji, podczas których atak zajęłby kilka lat.) Istnieją preimage ataki na zredukowane wersje SHA-1 Z znikomym skutkiem (dla zredukowanego SHA-1, który używa 44 kroków zamiast 80, Czas ataku jest krótszy od 2¹⁶⁰ operacje na 2¹⁵⁷). Są ataki kolizyjne na SHA-1, które są dobrze w teoretycznej possibility ( the best I found sprowadza czas z 2⁸⁰ na 2⁵²), ale są one bezużyteczne wobec hashów haseł, nawet bez solenia.

Krótko mówiąc, przechowywanie haseł za pomocą SHA-1 wydaje się całkowicie bezpieczne. Coś mnie ominęło?

Update: Marcelo wskazał na artykuł, który wspomina drugi atak preimage w 2¹⁰⁶ operacje . (Edit: jak wyjaśnia Thomas, atak ten jest hipotetycznym konstrukcja, która nie ma zastosowania do rzeczywistych scenariuszy.) Nadal nie rozumiem, jak to oznacza niebezpieczeństwo użycia SHA-1 jako funkcji wyprowadzania klucza. Czy istnieją ogólnie dobre powody, aby sądzić, że atak kolizji lub drugi atak preimage można ostatecznie przekształcić w pierwszy atak preimage?

141

hash cryptography sha1

Author: Community, 2010-05-05

Source

7 answers

Poprzednie odpowiedzi nie wspominają o GPU, które mogą paralelnie mieszać SHA-1 do tego stopnia, że cała baza danych może być teraz brutalnie wymuszona w ciągu minut lub godzin, a nie dni lub tygodni, nawet jeśli hasła zostały zasolone.

Nowoczesne algorytmy hashowania haseł, takie jak bcrypt lub scrypt, są zaprojektowane specjalnie tak, aby były trudne do uruchomienia na GPU ze względu na fakt, że są szyframi blokowymi o znacznie wyższych wymaganiach pamięci (a dostęp do pamięci w GPU nie może być równoległe w tym samym stopniu). Mają również "funkcję pracy", która pozwala im być wolniejsze w locie wraz z ulepszeniem technologii.

W skrócie, Należy używać tylko najlepszych narzędzi do pracy. I SHA-1 spada bardzo daleko od stanu techniki.

Do dalszych czytanie:

28

Author: jammycakes,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-04-13 12:48:18

Twój opis brzmi dokładnie jak aktualny stan techniki.

Nie powinieneś używać pojedynczej iteracji żadnej funkcji skrótu: przynajmniej powinieneś wielokrotnie powtarzać (1000 iteracji skrótu zwiększa pracę atakującego 1000-krotnie. Zwiększa twoją pracę o tę samą kwotę, ale robisz o wiele mniej haszowania haseł niż są).

Najlepiej jednak użyć istniejącego prymitywu przechowywania haseł, takiego jak opisane tutaj .

7

Author: Nick Johnson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-05 15:11:51

SHA1 jest message digest , to Nigdy nie miało być funkcją hashującą (lub wyprowadzającą klucze). (Chociaż może być używany jako budulec dla KDF, np. w PBKDF2 z HMAC-SHA1.)

Funkcja hashowania haseł powinna bronić się przed atakami słownikowymi i tablicami tęczowymi. Do osiągnięcia tego celu zaprojektowano kilka algorytmów.

Obecnie najlepszym wyborem jest prawdopodobnie Argon2. Ta rodzina funkcji haszujących hasła wygrała Konkurs hashowania haseł w 2015 roku.

Jeśli Argon2 nie jest dostępny, jedyną inną standaryzowaną funkcją hashującą lub wyprowadzającą klucze jest PBKDF2, która jest starym standardem NIST. Inne opcje, jeśli użycie standardu nie jest wymagane, obejmują bcrypt i scrypt.

Wikipedia ma strony dla tych funkcje:

6

Author: Erwan Legrand,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-07 10:42:24

W SHA-1 odkryto poważne luki, które sprawiają, że wyszukiwanie jest znacznie szybsze niż brute force. Nadal jest to w dużej mierze trudne do rozwiązania, ale nie oczekuje się, że będzie to miało miejsce zbyt długo; paranoiczni Programiści preferują coś z rodziny SHA-2.

From this article about the original 2005 result:

"Czas iść, ale nie biegać, do wyjść przeciwpożarowych. Nie widać dymu, ale włączyły się alarmy przeciwpożarowe."

To nie że obecna kryptoanaliza czyni SHA-1 niebezpiecznym, ale raczej że społeczność kryptograficzna obawia się, że gorsze wiadomości mogą być tuż za rogiem. Ten strach dotyczy również SHA-2, który wykazuje te same wady co SHA-1, aczkolwiek w znacznie większej przestrzeni poszukiwań, stąd trwające poszukiwania SHA-3.

Krótko mówiąc, SHA-1 jest teraz bezpieczny i prawdopodobnie będzie przez jakiś czas, ale społeczność kryptograficzna jest niewygodna z prognozami.

4

Author: Marcelo Cantos,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-05 10:05:52

Od Lutego 2017, SHA-1 nie powinien być już uważany za Bezpieczny. Google zgłosiło sukces dzięki atakom kolizyjnym na pełną, Nie zredukowaną rundę SHA-1 (link do raportu ). Aby zobaczyć ogłoszenie Google, Kliknij tutaj .

Edit: jak zauważyli inni, hasła nie są podatne na ataki hash collision. Jednak jako ogólne wytyczne nie wybrałbym SHA-1 dla aplikacji związanych z bezpieczeństwem. Istnieją lepsze alternatywy tam.

4

Author: Aaron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-02-24 05:51:05

Jeśli przechowujesz hasło solone, SHA-1 jest w porządku dla celów praktycznych. SHA-2 jest uważany za bardziej bezpieczny, ale SHA-1 nie jest problemem, chyba że masz powód do prawdziwej paranoi.

Oto co mówi NIST :

Wyniki zaprezentowane dotychczas na SHA-1 nie wzywaj jego bezpieczeństwa do pytanie. Jednak ze względu na postęp w technologii, NIST planuje stopniowe wycofywanie się z SHA-1 na korzyść większych i silniejsze funkcje haszujące (SHA-224, SHA-256, SHA-384 oraz SHA-512) przez 2010.

3

Author: VladV,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-05-05 10:07:15

score 203 · Accepted Answer

Krótka odpowiedź na twoje pytanie brzmi: SHA-1 jest tak bezpieczny,jak tylko możesz. MD5 też byłoby w porządku, nawet MD4; ale może to zdenerwować niektórych inwestorów. Dla public relations, najlepiej jest użyć "lepszej" funkcji skrótu, np. SHA-256, nawet jeśli obciąć jej wyjście do 160 lub 128 bitów (aby zaoszczędzić na kosztach przechowywania). Niektórzy kandydaci SHA-3 round-2 wydają się być szybsi niż SHA-1, będąc prawdopodobnie "bardziej bezpieczni"; jednak nadal są trochę nowi, więc trzymając się SHA-256 lub SHA-512 byłby teraz bezpieczniejszą drogą. To sprawi, że będziesz wyglądać profesjonalnie i ostrożnie, co jest dobre.

Zauważ, że "tak bezpieczne, jak można uzyskać" to nie to samo, co "całkowicie bezpieczne". Poniżej znajdują się dość długie wyjaśnienia.

O znanych atakach:

Znane ataki na MD4, MD5 i SHA-1 dotyczą kolizji, które nie mają wpływu na preimage resistance. Wykazano, że MD4 ma kilka słabych stron, które można (tylko teoretycznie) wykorzystać, próbując aby złamać HMAC / MD4, ale nie dotyczy to Twojego problemu. Na 2¹⁰⁶ drugi atak preimage w artykule kesleya i Schneiera to ogólny kompromis, który odnosi się tylko do bardzo długich wejść (2⁶⁰ bajtów; to milion terabajtów -- zauważ jak 106+60 przekracza 160; tam widzisz, że kompromis nie ma w sobie nic magicznego).

Reszta tej wiadomości zakłada, że używana funkcja hash (np. SHA-1) jest "czarną skrzynką" bez specjalnej właściwości, która atakujący może użyć. To właśnie masz teraz, nawet z" zepsutymi " funkcjami hashowymi MD5 i SHA-1.

O tęczowych tablicach:

"Tęczowy atak" jest w rzeczywistości dzieleniem kosztów w słowniku lub ataku brute force. Jest to pochodna kompromisu pamięci czasu po raz pierwszy opisanego przez Hellmana w 1980 roku. Zakładając, że masz N możliwe hasła (to rozmiar Twojego słownika, lub 2ⁿ jeśli rozważasz brutalne wymuszanie hasha funkcja z wyjściem N bitów), istnieje atak podziału czasu, w którym wstępnie obliczasz N hashowane hasła i przechowujesz je w dużej tabeli. Jeśli posortujesz wyniki hash, możesz uzyskać hasło w jednym wyszukiwaniu. Stół Tęczowy to inteligentny sposób przechowywania stołu o znacznie mniejszej przestrzeni. Przechowujesz tylko N / T hashowane hasła, a łamiesz hasła za pomocą O ( t²) Szukaj. Stoły Rainbow pozwalają praktycznie obsługiwać stoły znacznie większe niż to, co można realistycznie przechowywać.

Jednakże, rainbow czy nie, atakujący musi wykonać cały atak przynajmniej raz. Można to postrzegać jako kilka kolejnych warstw optymalizacyjnych:

atak brute-force / dictionary ma koszt N za złamanie każdego hasła.
z wstępnie obliczoną tabelą, atakujący płaci ten koszt N raz , a następnie może zaatakować Wiele haseł z bardzo małymi dodatkowymi kosztami na hasło.
jeśli wstępnie obliczona tabela jest tabelą tęczową, to N może być nieco większa, ponieważ koszt przechowywania jest zmniejszony. Wąskie gardło na N staje się mocą procesora, którą atakujący może zgromadzić, a nie rozmiarem jego dysków twardych.

Jeśli N jest na tyle duży, że koszt hashowania N haseł jest absurdalny, to taki atak nie jest możliwy, niezależnie od tego, czy używane są tabele rainbow. Oznacza to, że (preimage-resistant) funkcja hash z wyjściem 80 bitów lub więcej jest wystarczająca, aby atak brute-force był nieosiągalny.

O Sole:

Sole są sposobem na pokonanie przed obliczeniami. W powyższym opisie sól przywraca atakującemu Krok 1: sól uniemożliwia atakującemu dzielenie kosztów O (N ) między kilkoma atakowanymi hasłami. Wstępnie obliczone tabele, a fortiori tęczowe tabele, nie są już wykonalne.

Chcesz solenie ponieważ gdy dane zaszyfrowane składają się z haseł, tzn. czegoś, co mieści się w mózgu przypadkowego człowieka, to N może być dość niski: ludzie są naprawdę źli w wyborze i zapamiętywaniu haseł. O to właśnie chodzi w" atakach słownikowych": to użycie ograniczonej przestrzeni potencjalnych haseł ("słownik") przy założeniu, że wiele haseł użytkowników będzie w tej specjalnie wybranej przestrzeni.

Dlatego solenie przynajmniej zapobiegnie atakującemu korzystanie z wstępnie obliczonych tabel, w szczególności wstępnie obliczonych tabel tęczowych. Zakłada to, że atakujący będzie w stanie złamać jedno lub dwa hasła; nie chcemy, aby złamał 1000 innych haseł z niewielką ilością dodatkowych kosztów.

Również solenie jest dobre dla public relations.

O koszcie SHA-1:

Podstawowy koszt SHA-1 polega na zaszyfrowaniu 64-bajtowego bloku. Tak działa SHA-1: Dane są wyściełane, a następnie dzielone na 64-bajtowe bloki. Koszt przetwarzania a pojedynczy blok to około 500 cykli zegara w systemie Intel Core2, a to dla pojedynczego rdzenia. MD5 I MD4 są szybsze, liczą odpowiednio około 400 i 250 cykli. Nie zapominaj, że większość nowoczesnych procesorów ma kilka rdzeni, więc odpowiednio pomnożyć.

Niektóre schematy solenia przepisują ogromne sole; np. to, co wchodzi w funkcję hash, to w rzeczywistości 40000 kolejnych kopii pojedynczego 128-bitowego soli, a następnie samo hasło. To sprawia, że hashowanie haseł jest droższe (o współczynnik 10000 z mój przykład), zarówno dla uprawnionego użytkownika, jak i dla atakującego. To, czy jest to dobry pomysł, zależy od konfiguracji. W przypadku logowania w systemie stacjonarnym jest to dobre: użytkownik nawet nie zauważy, że hashowanie hasła zajęło 10ms, zamiast 1µs; ale koszt atakującego wzrósł o bardzo zauważalny czynnik 10000. Na współdzielonych serwerach z tysiącami klientów na sekundę łączny koszt może stać się wygórowany. Koncepcyjnie, podniesienie poprzeczki o ten sam czynnik dla uprawnionego użytkownika i atakujący nie jest ostatecznie dobrym zabezpieczeniem; ale może to być wartościowy pomysł w niektórych szczególnych sytuacjach.

O atakach online:

Wszystko to polega na pokonywaniu ataków offline. Atak offline to atak, w którym atakujący ma wszystkie dane potrzebne do "testowania" haseł; np. atakujący może uzyskać kopię bazy danych z hashowanymi hasłami. W ataku offline atakujący jest ograniczony tylko przez swoje zasoby obliczeniowe. I odwrotnie, atak online jest atakiem, w którym każde odgadnięcie przez atakującego musi przejść przez uczciwego weryfikatora (np. atakujący po prostu próbuje zalogować się do zaatakowanego systemu). Ataki Online są udaremniane przez egzekwowanie limitów liczby haseł, które można wypróbować na sekundę. Ekstremalnymi przykładami są smartcards, które wyłączają się po trzech błędnych pinach.

Zazwyczaj, dla bezpieczeństwa hasła, dużo bardziej opłaca się zorganizować system, aby nie pozwolić atakującemu zbudować ataku offline. To właśnie robią systemy uniksowe: hashowane hasła, które kiedyś znajdowały się w pliku /etc/password czytelnym dla świata, są teraz w pliku /etc/shadow, który jest chroniony przed dostępem do odczytu, z wyjątkiem kilku uprzywilejowanych aplikacji. Zakłada się tutaj, że jeśli atakujący może odczytać /etc/shadow, to prawdopodobnie ma wystarczającą kontrolę nad systemem, że tak naprawdę nie potrzebuje już haseł...