Tak, porównanie ciągów (i/lub wyszukiwanie indeksu) może w zasadzie ujawnić, ile identycznych wiodących bajtów hash hasła jest przechowywany w bazie danych i ten obliczony z wprowadzonego udziału hasła.
W zasadzie atakujący może użyć tego do iteracyjnego uczenia się prefiksu skrótu hasła, bajt po bajcie:najpierw znajduje skrót, który dzieli swój pierwszy bajt z haszem w bazie danych, a następnie taki, który dzieli swoje pierwsze dwa bajtów i tak dalej.
Nie, to prawie na pewno nie będzie miało znaczenia.
Czemu? Cóż, z wielu powodów:
-
Atak czasowy może umożliwić atakującemu poznanie części skrótu hasła użytkownika. Dobrze zaprojektowany schemat haszowania hasła (przy użyciu soli i rozciągania klucza ), jednak powinny pozostać bezpieczne (zakładając oczywiście, że same hasła nie są łatwe do odgadnięcia), nawet jeśli atakujący zna całość hash hasła. Dlatego nawet jeśli atak czasowy się powiedzie, same hasła będą bezpieczne.
-
Aby przeprowadzić atak, atakujący musi podać hasła, których wartość skrótu zna. Wartość mieszania zależy od soli. Zatem chyba że atakujący w jakiś sposób nie zna już soli, ten atak nie jest możliwy.
(Prawdą jest, że w większości analiz bezpieczeństwa schematów haszowania haseł, sól jest uznawana za informację publiczną. Jednak dzieje się tak tylko dlatego, że takie analizy zakładają najgorszy scenariusz, o którym mowa powyżej, w którym atakujący uzyskał już kopię całą bazę danych użytkowników, sole i haszy i tak dalej. Jeśli atakujący nie zna jeszcze hasha, nie ma powodu zakładać, że zna sól.)
-
Nawet jeśli atakujący zna sól, aby przeprowadzić opisany powyżej atak iteracyjny, będzie musiał wygenerować hasła haszujące do wartości z żądanym prefiksem. W przypadku każdej bezpiecznej funkcji skrótu jedynym praktycznym sposobem na zrobienie tego jest próba błędu, co oznacza, że czas potrzebny na wykonanie tej czynności rośnie wykładniczo wraz z długością prefiksu.
W praktyce oznacza to, że w celu wydobycia wystarczającej liczby bitów skrótu, aby móc przeprowadzić przeciwko niemu atak brute force offline (który nie musi obejmować wszystkich; po prostu więcej niż efektywna ilość entropii w hasło), atakujący musi wykonać tyle obliczeń, ile jest wymagane do złamania samego hasła. W przypadku dobrze zaprojektowanego schematu haszowania hasła i bezpiecznie wybranego hasła nie jest to możliwe.
-
Co może atak iteracyjny? w zasadzie daje atakującemu możliwość wykonywania większości obliczeń siłowych lokalnie na swoim końcu, jednocześnie przesyłając tylko niewielką liczbę haseł do swojego systemu. Jednak nawet to obowiązuje tylko wtedy, gdy otrzymają szczegółowe i wiarygodne informacje o czasie z powrotem od każdego hasło przesłane. W praktyce prawdziwe ataki czasowe są wyjątkowo nieefektywne i wymagają wielu (często tysięcy lub milionów) zapytań, aby uzyskać dowolne przydatne informacje. Najprawdopodobniej zniweluje to jakąkolwiek potencjalną przewagę wydajności, jaką atak czasowy mógłby zapewnić atakującemu.
Ten punkt jest wzmocniony, że używasz właściwego schematu haszowania hasła polegającego na rozciąganiu klucza, ponieważ takie schematy są celowo zaprojektowane tak, aby były powolne. W ten sposób porównanie ciągów w bazie danych prawdopodobnie zajmie niewiele czasu w porównaniu z haszowaniem hasła, a wszelkie spowodowane przez to zmiany czasu zostaną utracone w szumie.
