Paweł Goleń, blog

Chodzi mi w szczególności o sytuację, w której w trakcie testu bezpieczeństwa sieci lub aplikacji wykonywana jest próba łamania/zgadywania haseł. Można wykorzystać różnego rodzaju narzędzia, że wspomnę tylko o Cain & Abel, Hydra, Medusa, John the Ripper czy Ophcrack. Osobiście uważam taki test za stosunkowo mało wiarygodny, choćby dlatego, że:

• raczej nigdy nie sprawdza się całej przestrzeni haseł (bo nie ma czasu),
• czas testu penetracyjnego jest ograniczony (patrz wyżej), czas działania atakujących - nie,
• ONI mogą mieć lepsze tablice (rainbow tables) czy słowniki,
• mogą mieć więcej szczęścia,
• mogą zebrać więcej informacji o obiekcie ataku (konkretnej osobie) i odgadnąć hasło,
• (...)

Oczywiście, sprawdzenie w trakcie testu penetracyjnego listy domyślnych haseł dla poszczególnych usług/aplikacji ma sens i kończy się w zaskakująco wielu przypadkach powodzeniem, jednak (tu odzywa się moja druga natura byłego bezpiecznika) wyeliminowanie tego typu podatności nie gwarantuje, że użytkownicy nie mają słabych haseł. Kiedyś słynny L0phtCrack był sprzedawany jako narzędzie dla administratorów systemów przeznaczone do "audytu haseł użytkowników". Zresztą przyznam, że ja również kilka razy w ten sposób nawyki użytkowników sprawdzałem, choć za pomocą wspomnianego wcześniej Cain & Abel właśnie.

Moim zdaniem lepszym rozwiązaniem jest weryfikacja istnienia i stosowania polityki haseł. Pozwala to wyrobić sobie pogląd na temat jakości haseł użytkowników - nie są oni w stanie wykorzystać haseł, które ustanowionej polityki nie spełniają. W szczególności warto jest sprawdzić:

• minimalną długość hasła,
• maksymalną (uwzględnianą) długość hasła,
• czas życia hasła (co ile trzeba je zmieniać),
• historię haseł (czy można zmienić na jedno z poprzednich),
• wymagania co do stosowanych w haśle znaków,
• czy hasło jest blokowane po nieudanych próbach uwierzytelnienia, a jeśli tak to po ilu próbach i na jaki czas,

Można dyskutować jakie wartości należy uznać za wystarczające. Sam zalecam stosowanie przynajmniej dwóch wymagań: długości minimalnie 8 znaków oraz wymagania znaków spośród trzech z czterech grup (duże litery, małe litery, cyfry, znaki specjalne). Jeśli nawet na znaki specjalne wprowadzone zostanie ograniczenie dopuszczające przykładowo znaki $@#, to i tak w najgorszym wariancie do sprawdzenia atakujący będzie miał co najmniej (26+10+3)^8 co daje przestrzeń 5 352 009 260 481 możliwych haseł. Jeśli taka polityka jest stosowana, można dodatkowo empirycznie sprawdzić istniejące hasła słownikowo, nawet wykorzystując pewien "fuzzing" słowników. Wydłużając minimalną długość hasła do 10 znaków otrzymuje się już przestrzeń liczącą (znów - w najgorszym przypadku) 8 140 406 085 191 601 możliwych haseł.

Dla porównania dzień to 86 400 sekund, rok - 22 896 000. Ile czasu może atakujący poświęcić na łamanie haseł? Dzień, miesiąc? Rok? Ile musiałby sprawdzać haseł na sekundę, by przy konkretnej polityce haseł, mógł sprawdzić wszystkie? Ale o tym już w kolejnym odcinku/odcinkach.