Uwierzytelnianie w systemie MS Windows

Metody uwierzytelniania w MS Windows ewoluowały wraz z kolejnymi wersjami systemu oraz kolejnymi odkrywanymi lukami. Pierwszym protokołem był LAN Manager Challenge/Response. Jednak ze względu na fakt, iż do złamania hasła wysłanego za pomocą LM wystarczy kilka godzin, został on zastąpiony przez Windows NT LAN Manager Challenge/Response. Protokół ten korzystał z silniejszej funkcji haszującej, jednak podczas transmisji przesyłał wartość skrótu w sposób jawny, co jest podatne na podsłuch. Dlatego też powstał NTLMv2, w którym dodano zabezpieczenia sesji.

Domyślnie w systemie MS Windows aktywowane są metody LM oraz NTLM. Dlatego w celu zwiększenia bezpieczeństwa należy zmienić obsługę uwierzytelniania na NTLMv2. W tym celu należy wymusić negocjację protokołu uwierzytelniania na NTLMv2, a w systemach MS Windows 2000, MS Windows XP oraz MS Windows 2003 należy zmienić wartość rejestru

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LMCompatibilityLevel na jedną z poniższych opcji:

• 0 - Wyślij odpowiedź typu LM i NTLM; nie używaj zabezpieczeń sesji NTLM 2. Klienci korzystają z uwierzytelniania LM i NTLM i nigdy nie używają zabezpieczeń sesji NTLM 2; kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLM 2.
• 1 - Użyj zabezpieczeń sesji NTLM 2, jeżeli są negocjowane. Klienci korzystają z uwierzytelniania LM oraz NTLM i używają zabezpieczeń sesji NTLM 2, jeżeli są one obsługiwane przez serwer; kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLM 2.
• 2 - Wyślij tylko odpowiedź typu NTLM. Klienci korzystają tylko z uwierzytelniania NTLM i używają zabezpieczeń sesji NTLM 2, jeżeli są one obsługiwane przez serwer; kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLM 2.
• 3 - Wyślij tylko odpowiedź typu NTLM 2. Klienci korzystają z uwierzytelniania NTLM 2 i używają zabezpieczeń sesji NTLM 2, jeżeli są one obsługiwane przez serwer; kontrolery domeny akceptują uwierzytelnianie LM, NTLM i NTLM 2.
• 4 - Kontrolery domeny odmawiają odpowiedzi typu LM. Klienci korzystają z uwierzytelniania NTLM i używają zabezpieczeń sesji NTLM 2, jeżeli są one obsługiwane przez serwer; kontrolery domeny odmawiają uwierzytelniania LM (tzn. akceptują uwierzytelnianie NTLM i NTLM 2).
• 5 - Kontrolery domeny odmawiają odpowiedzi typu LM i NTLM (akceptują tylko uwierzytelnianie NTLM 2). Klienci korzystają z uwierzytelniania NTLM 2 i używają zabezpieczeń sesji NTLM 2, jeżeli są one obsługiwane przez serwer; kontrolery domeny odmawiają uwierzytelniania NTLM i LM (tzn. akceptują tylko uwierzytelnianie NTLM 2).

Opcje 0-3 dotyczą części klienta, natomiast opcje 4-5 części serwera.

Użytkownicy wcześniejszych wersji systemu operacyjnego MS Windows również mają możliwość skorzystania z nowszych wersji protokołów uwierzytelniania. W tym celu należy zainstalować "Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0". Po jego instalacji należy wykonać następujące zmiany w rejestrze:

1. Uruchamiamy program regedit.exe (Menu Start -> Uruchom -> regedit.exe OK)
2. Wyszukujemy klucz HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
3. Ustalamy odpowiednią wartość LMCompatibilityLevel:

Uwierzytelnianie w domenie Active Directory oparte jest o protokół Kerberos v5, w którym generowane są bilety umożliwiające dostęp do usług sieciowych. Bilety zawierają zaszyfrowane dane, w tym zaszyfrowane hasło, które potwierdza tożsamość użytkownika w żądanej usłudze. Z wyjątkiem czynności wprowadzania hasła lub poświadczania karty inteligentnej cały proces uwierzytelniania jest niewidoczny dla użytkownika.

Ważną usługą protokołu Kerberos v5 jest Centrum dystrybucji kluczy (KDC). Centrum KDC działa na każdym kontrolerze domeny jako część usługi katalogowej Active Directory, która przechowuje wszystkie hasła klientów i inne informacje o kontach.

Hasła w systemach Unix

Hasła w systemach Unix przechowywane są w plikach /etc/passwd lub /etc/shadow w postaci skrótów. Podczas haszowania używana jest sól, która zwiększa bezpieczeństwo hasła. Hasła przechowywane w pliku /etc/passwd były widoczne dla wszystkich użytkowników. Dawało to możliwość łatwego podejrzenia zakodowanych haseł wszystkim użytkownikom. Dlatego postanowiono rozdzielić informacje o hasłach od informacji o użytkowniku - zaczęto korzystać z pliku /etrc/shadow, do którego dostęp ma tylko root. Użycie soli powoduje, że techniki oparte na obliczonych wcześniej haszach nie sprawdzają się - należałoby obliczyć skróty dla wszystkich możliwych wartości soli, co przy 2 bajtach daje już liczbę 65 536 razy większą. Należy jednak pamiętać, że początkowo wykorzystywana sól miała tylko 12 bitów. Daje to jedynie 4096 razy więcej kombinacji. Przy dzisiejszych możliwościach nie jest to wcale tak dużo. Dodatkowo algorytm crypt(3) używany pierwotnie w systemach Unix bazował na dość słabym algorytmie DES. Pozwalał utworzyć on skrót haseł nieprzekraczających 8 znaków.

Używanie funkcji haszujących wraz z solą sprawia, że zakodowane hasła można próbować odkryć tylko za pomocą ataku siłowego lub słownikowego.

W tym celu można wykorzystać popularne oprogramowanie John the Ripper.

<hr size="1" noshade />Krzysztof Maćkowiak jest autorem serwisu www.kryptografia.com, członkiem Polskiego Towarzystwa Informatycznego i ISACA International. Współpracuje z firmą Doradztwo Gospodarcze DGA SA jako konsultant ds. bezpieczeństwa informacji.

Piotr Gawron pracuje na Politechnice Poznańskiej jako administrator sieci komputerowej, współpracuje też z firmą Doradztwo Gospodarcze DGA SA w zakresie przeprowadzania audytów bezpieczeństwa teleinformatycznego.