Hasła trudne do odgadnięcia

Jakie haslo jest bezpieczne? Takie, które trudno jest odgadnac. Istnieja tutaj dwa aspekty: pierwszy, dotyczacy hasel latwych do powiazania z kolega z pracy (numer rejestracyjny, imie kota czy data urodzin zony) i drugi – bazujacy na wyjatkowej popularnosci hasel takich jak qwerty, blahblah czy hello123. W polskich realiach duza popularnosc maja tez wulgaryzmy, ale przytaczanie ich tutaj wydaje sie zbedne ;)

Pierwszy przypadek dotyczy "przyjacielskich" ataków i jezeli ktos uzywa hasla prostego to powiazania ze swoim zyciem codziennym – sam sie o zaatakowanie prosi.

Drugi przypadek jest trudniejszy. Skad biedny uzytkownik ma wiedziec, ze jego super tajne haslo "volcom1" jest jednym z najczesciej uzywanych? Jakims podejsciem sa slowniki zabronionych hasel, ale to rozwiazuje tylko czesc problemu.

Z dobrym pomyslem przychodzi tutaj niezawodna jak zawsze ekipa Microsoft Research. W jednym z dokumentów, zaproponowali, aby sztywne reguly polityki hasel zastapic elastycznym wymogiem, aby nowe haslo nie bylo takie samo jak któres z najpopularniejszych hasel w danym srodowisku. Idea jest naprawde ciekawa: system broni sie sam, poniewaz kazde nowe haslo jest sprawdzane pod katem popularnosci. Jaki to ma efekt w praktyce, latwo sobie wyobrazic, wiedzac na przyklad, ze na forach bazujacych na phpBB ponad 8% hasel udaje sie odgadnac w pieciu próbach (123456, password, phpbb, qwerty, 12345).

Implementacja polityki bazujacej na popularnosci hasel jest w przypadku serwisów WWW dosc prosta i nie trzeba jej chyba tutaj omawiac. Warto natomiast zastanowic sie przez pare chwil jak to zrobic w srodowisku bazujacym na Active Directory. Wbrew pozorom nie jest to trudne. System Windows przy kazdej zmianie hasla wywoluje z zarejestrowanych bibliotek DLL funkcje PasswordFilter() i przekazuje jej haslo z pytaniem, czy jest ono dozwolone. Tak wiec, wystarczy napisac kawalek kodu, zapamietujacy na przyklad MD5 dla kazdego nowego hasla i sprawdzajacy jak czesto dana suma kontrolna wystepuje na liscie.

Poza sama idea, oczywiscie warto skupic sie na naprawde istotnych detalach takich jak:

• Koniecznosc bezpiecznego przetwarzania hasel przez PasswordFilter() i bezpiecznego przechowywania skrótów
• Koniecznosc podlaczenia biblioteki DLL na kazdym kontrolerze domeny
• Madre wyliczanie funkcji skrótu (na przyklad od drugiego do ósmego znaku hasla) tak, aby samym faktem odrzucenia hasla jako zbyt popularne nie dac zbyt oczywistej podpowiedzi atakujacemu, ze ktos takiego hasla juz uzywa.

Na liscie najpopularniejszych hasel warto równiez umiescic hasla historyczne. Dzieki temu, poza wieksza baza sprawdzanych ciagów znaków zyskamy równiez zabezpieczenie przed "recyclingiem" hasel oraz budowaniem hasel na bazie tego samego trzonu, ze zmieniajaca sie koncówka odpowiadajaca na przyklad numerowi miesiaca.

Oczywiscie, cale wszystkie te dywagacje maja sens wtedy, gdy hasla sa "same z siebie" bezpieczne, czyli gdy do ich odgadniecia jest potrzebna odpowiednio duza ilosc prób. Ale to juz zupelnie inny temat, omawiany juz wczesniej na tym blogu.

Autor: Grzegorz Tworek [MVP]

Comments

• Anonymous
  January 01, 2003
  No mi się zdarzało... I nie zawsze celem było tylko filtrowanie ;) Tak poważniej, to wydaje mi się, że ta funkcjonalność trochę została zapomniana i jej przypomnienie nie zaszkodzi. Napisanie takiej DLLki jest stosunkowo proste nawet dla nie-programisty. A nuż ktoś spróbuje?

• Anonymous
  January 01, 2003
  Każdy czyta poradniki mniej więcej na swoim poziomie. Nikogo nie przekonuję, że blog technet jest bardziej właściwy niż onet. Dla jednych jest, dla innych nie i na szczęście zasobów w Internecie nie brakuje.

• Anonymous
  July 27, 2010
  Grzesiek, tak z ciekawosci: ile znasz osob, ktore napisza dlla z PasswordFilter() i skorzystaja z niego w AD?

• Anonymous
  July 29, 2010
  hehe, ale się uśmiałam :D to już poradniki na onecie są sensowniejsze i bardziej merytoryczne.