Podręcznik
2. Kryptografia
2.3. Przechowywanie i weryfikacja haseł
Jednym z częstszych błędów jest niepoprawne przechowywanie haseł w bazach danych użytkowników oraz niewłaściwe podejście do procesu ich weryfikacji. Problem ten może narażać nie tylko samą aplikację, ale także użytkowników, którzy wykorzystując powtarzalne schematy haseł po ujawnieniu ich w jednym wycieku stają się ofiarami ataków na inne systemy. Spójrzmy na możliwe problemy i ich źródła.
Podstawową, zalecaną metodą przechowywania hasła w bazie danych jest wykorzystanie dedykowanej do tego celu kryptograficznej funkcji skrótu (Argon, scrypt, bcrypt, PBKDF2) z dołączonym ziarnem - komponentem losowym (salt). Zapewnia to odpowiednią odporność na różnego rodzaju ataki przedstawione poniżej.
Można to jednak zrobić źle:
- przechowywanie haseł jawnym tekstem – najgorszy scenariusz, gdzie po ujawnieniu bazy danych hasła są natychmiast dostępne dla atakującego, dodatkowo, często algorytm porównujący jest podatny na atak side-channel (patrz dalej), gdyż sprowadza się do porównania dwóch ciągów znaków,
- szyfrowanie stałym kluczem bez komponentu losowego (Adobe.com [13]) – w przypadku tego zdarzenia popełniono dwa błędy – wykorzystano stały klucz oraz tryb szyfrowania ECB, który ujawnia podobieństwo haseł różnych użytkowników,
- wykorzystanie funkcji skrótu z hasła bez komponentu losowego – ujawnia podobieństwo haseł różnych użytkowników,
- wykorzystanie podatnej na ataki funkcji skrótu (np. SHA1, MD5), lub funkcji skrótu nieposiadających cech kryptograficznych – umożliwia wygenerowanie hasła o takiej samej funkcji skrótu w skończonym czasie (hasło nie musi być identyczne, ale będzie miało taką samą funkcję skrótu), atak powiedzie się nawet przy wykorzystaniu komponentu losowego,
- wykorzystanie szybkiej w obliczeniach funkcji skrótu – podatność na ataki brutalne polegające na podawaniu kolejnych ciągów znaków wyczerpujących wszystkie możliwe kombinacje – długotrwałe, ale np. dla funkcji skrótów wykorzystywanych w blockchain-ach znamy bardzo szybkie implementacje, w tym na kartach graficznych lub dedykowanych układach scalonych.
Stąd zalecenie wykorzystania do przechowywani haseł:
- funkcji skrótu o dużym nakładzie obliczeniowym, w szczególności nie pasującej architekturą do modelu obliczeniowego kart graficznych (Argon2d [14]) – zapewnia odporność na ataki brutalne [17],
- komponentu losowego ziarna (salt) – zapewnia różny wynik funkcji skrótu w przypadku identycznych haseł.
Problem przechowywania hasła to jedna z dwóch stron procesu weryfikacji. Drugim problemem jest sposób weryfikacji hasła. W większości przypadków model weryfikacji hasła polega na przesłaniu jego otwartotekstowej wersji zaszyfrowanym kanałem a następnie, po wykonaniu tych samych przekształceń, które były niezbędne do zachowania informacji o haśle i porównaniu tak uzyskanych skrótów algorytmem o stałym czasie wykonania bez względu na wynik porównania. Model ten zakłada zaufanie do kanału komunikacyjnego.
W kategorii podatności systemu haseł należy także wymienić:
- umożliwienie ataków zautomatyzowanych bez dodatkowych
utrudnień typu CAPTCHA (Completely Automated Public Turing test to tell
Computers and Humans Apart) czyli sposobów na weryfikację, że to człowiek wykonuje
określoną czynność, pamiętajmy jednak, że CAPTCHA nie jest stuprocentowym zabezpieczeniem i istnieją ataki obejścia [62],
- dopuszczenie wykorzystania prostych haseł, mających komponenty słownikowe, krótkich, popularnych w wyciekach – metodą obrony jest tutaj weryfikacja stopnia skomplikowania hasła oraz występowania w znanych bazach wycieków,
- ograniczanie długości hasła, wprowadzenie wymagań na konstrukcję hasła zamiast jego wydłużenia – sztucznie wprowadzone ograniczenie długości w połączeniu z wymogiem wykorzystania odpowiedniej kategorii znaków prowadzi do budowania przez użytkowników prostych i powtarzalnych schematów – opartych na układach klawiszowych, zawierających słowa słownikowe, znaki ‘1’ oraz ‘!’ jako spełnienie wymagania cyfra i znak specjalny etc. [15],[16]
- użycie mechanizmu pytań pomocniczych jako metody weryfikacji w przypadku procedury odzyskiwania konta –podpowiedź często zawiera samo hasło, lub informację trywializującą jego odzyskanie, a zapewne zostanie w bazie danych zachowana w sposób otwarty (por. wyciek adobe.com),