podwójne hashowanie haseł, ogólnie n-hashowanie Opcje

[nospor]

w związku z lekkim OT w pewnym temacie, który rozwinął się w ciekawą dyskusję, temat rozdzielam. Dotyczy on:
Czy podwójne (n-te) hashowanie hasła jest bezpieczniejsze, od pojedynczego hashowania

md5 sie nie odkoduje. mozna trafic na rozwiązanie metodą brute force. Dla tej metody jednak jest bez roznicy, czy ty dane haslo przepuścic przez md5 raz, dwa czy milion razy

Posty będące duplikacją postów już zawartych w temacie, będą bez ostrzeżenia usuwane. Ma to zapobiedz tworzeniu się zbędnego śmietnika

[yevaud]

Często w tym wątku pojawia się problem szybkości algorytmu hashowania. Martwicie się, że algorytm będzie wolny, cieszycie się gdy md5 jest superszybkie. Wydaje mi się, że to podstawowy błąd na poziomie założen. Funkcje hashujące których używamy - i nie ważne czy będzie to md5, czy coś z rodziny sha2, albo nawet cos bardziej ekscentrycznego jak haval - nie zostały zaprojektowane do szyfrowania kilku/kilkunasto znakowych haseł, a do hashowania dużych bloków danych, lub do hashowania duzych ilości skrótów w bardzo krótkim czasie(np. podczas sortowania, lub w implementacji protokołu sieciowego). One naprawde SĄ szybkie:)

W przypadku haseł w serwisie webowym, operacja hashowania wykonywana jest tylko raz na każde logowanie, więc nie musi być bardzo szybka. Różnice zajętości ramu podczas obliczeń na poziomie kilu kb także nie są tutaj problemem. Dodatkowo np. obliczanie hasha nie powinno dać się zrównoleglić. Można pewnie wymienić jeszcze kilka założeń które będą prawdziwe dla haseł serwisu webowego, a niekoniecznie prawdziwe przy innych zastosowaniach.

Popatrzmy w jaki sposób można zaatakować hash w serwisie webowym:

a) brute-force. Najbardziej rozpowszechniona i najłatwiejsza metoda ataku.
Problemem jest bardzo duża szybkość komputerów. Atakujący może wygenerować olbrzymie ilości hashów w krótkim czasie. Dodatkowo niezabezpieczony formularz logowania może pozwalać na wielokrotne logowania w krótkim czasie. Za kilkaset $/h można wynając superkomputer obliczający 500,000,000,000 hashy na sekundę!

slownik/brute-force
Problemem jest mała inwencja użytkowników przy wymyślaniu haseł

c) rainbow
Problemem jest generalnie brak "soli" Atakujący ma wygenerowany słownik hashy

d) analiza różnicowa i inne metody matematyczne
W typowym serwisie webowym nie jest to problem, jednak warto pamiętać, że md5(md5($val)) będzie miało prawdopodobnie gorsze właściwości, niż pojedyńcze użycie funkcji hashującej, dlatego należy raczej unikać takiego rozwiązania. Problem wielokrotnego hashowania typu md5(md5(md5(...) leży prymitywnym sposobie podawania danych do funkcji -> tylko za pierwszym razem używamy całości dostępnych danych, za każdym następnym razem do funkcji hashującej wchodzą zawsze dokladnie 32 znaki, a większość "losowości" która tkwiła w oryginalnym haśle, jest (prawdopdobnie) powoli tracona przez funkcje mieszającą. Piszę prawdopodobnie bo nie udało się udowodnić do tej pory ani że jest tracona ani że nie jest, można jednak dość bezpiecznie założyć, że stałe 32 znaki poddawane cały czas temu samemu algorytmowi, maja raczej gorsze właściwości niż losowy ciąg znaków

e) atak DOS
W przypadku serwisu webowego, atak na kolizję przy logowaniu nie ma za bardzo sensu, ale jeśli operacja hashowania jest kosztowna, można doprowadzić do wyczerpania zasobów serwera np. poprzez wielokrotne logownie.


Teraz remedium na nasze problemy:
e) ograniczenie ilości logowań, albo szybka funkcja hashująca
d) używanie całości danych wejściowych przy każdej iteracji algorytmu hashującego, używanie matematycznie poprawnych funkcji hashujących
c) sól.
Słownik i odrzucanie idiotycznych haseł użytkowników. Narzucenie odpowiedniego poziomu skomplikowania na hasła.
a) Wolny algorytm hashowania! przez wolny, rozumiem np. ~10ms

No włąsnie, jak widać na końcu szybki algorytm hashujący, jest tak naprawde WADĄ w przypadku typowego serwisu webowego.

Po tym przydlugim wstępie, przejdę do sedna:
http://en.wikipedia.org/wiki/Bcrypt - nie mylić z http://bcrypt.sourceforge.net/
jest to algorytm który spełnia założenia które sobie postawiliśmy. Jest matematycznie poprawny, oparty na sboxach z blowfisha, a do tego można sterować jego złożonością tak żęby osiągnąć wymaganą szybkość(a raczej wolność). Niewielka modyfikacja w szybkości funkcji hashującej i atakujący który próbuje bruteforce potrzebuje nagle lat zamiast minut na złamanie haseł, a dla naszego serwisu różnica rzędu paru ms przy logowaniu nie jest zauważalna.

http://stackoverflow.com/questions/4795385...asswords-in-php

Podsumowując:
1. wolna, poprawna matematycznie funkcja hashująca typu bcrypt
2. słownik
3. ograniczenie ilości logowań
4. sól

Ten post edytował yevaud 31.07.2011, 19:21:50