Określanie wymagań dotyczących złożoności haseł w GPO

W poprzednim wpisie wyjaśniałem czym jest silne hasło oraz wyjaśniałem na konkretnych liczbach dlaczego należy je stosować. W tym wpisie chciałbym skoncentrować się na przedstawieniu dostępnych opcji związanych z hasłami oraz kontem użytkownika, znajdujących się w GPO.

W szczególności osoby zajmujące się bezpieczeństwem z pewnością wiedzą jak dużym problemem jest stosowanie słabych haseł przez zwykłych użytkowników. Pomimo ciągłego przypominania o istocie tej kwestii, przygotowywania szkoleń z zakresu bezpieczeństwa i próbowania wszelkich innych form dotarcia do użytkownika, aby uświadomić mu skalę problemu, nie jesteśmy w stanie dotrzeć do niezainteresowanych tą tematyką użytkowników. Osobom świadomym nie trzeba tłumaczyć istoty posiadania silnych haseł, dlatego niezbędne jest podjęcie wszelkich możliwych kroków, aby poprawić bezpieczeństwo w tym zakresie. Nawet jeżeli nie będziemy w stanie wpłynąć na użytkowników w taki sposób, by zaczęli w świadomy sposób zwracać uwagę na złożoność tworzonych przez nich haseł, jesteśmy w stanie częściowo rozwiązać problem wymuszając określone reguły co do ich tworzenia.

Definiowanie odpowiednich wymagań co do tworzonych haseł pokrywa tylko część problemów. Owszem, jesteśmy w stanie zadbać o to, by hasła były odpowiednio długie czy składały się z różnego typu znaków, ale nie mamy możliwości kontroli tego, jak dokładnie będzie wyglądało takie hasło. Przecież „Amadeusz123!” spełni większość definiowanych wymagań dotyczących haseł – ma znaki pochodzące nawet nie z 3, a 4 różnych grup, jest sensownej długości, a mimo to nie jesteśmy w stanie nazwać takiego ciągu silnym hasłem. Mimo wszystko zdecydowanie lepiej jest zrobić cokolwiek, aby choć trochę podnieść poziom bezpieczeństwa, niż nie robić w danym zakresie nic. Ale przejdźmy do konkretów.

Wymagania dotyczące haseł możemy konfigurować zarówno z poziomu domeny, jak i lokalnie. Odpowiadające za to ustawienia możemy znaleźć w następującym miejscu:

W zakładce Password Policy znajdziemy kilka możliwych do skonfigurowania polityk, które postaram się obszernie omówić posiłkując się realnymi przykładami – przedstawiane tu domyślne wartości są domyślnymi wartościami dla domenowego GPO, w przypadku GPO lokalnego wartości często nie są w ogóle domyślnie zdefiniowane:

• Enforce password history – opcja, która pozwala na zapamiętanie określonej ilości haseł, które stosował w przeszłości użytkownik. Domyślnie system Windows zapamiętuje 24 ostatnie hasła i w sytuacji, gdy użytkownik będzie chciał zmienić swoje hasło na jedno z 24 ostatnio wykorzystywanych – nie będzie to możliwe. Jest to bardzo istotne ustawienie, które w niewielkim stopniu może wpłynąć także na walkę z przewidywalnymi, słownikowymi hasłami. W ten sposób użytkownik, którego zmuszamy do regularnej zmiany hasła (o czym później) będzie miał ograniczone możliwości w stosowaniu popularnych, łatwych do zapamiętania haseł typu „Styczeń2020!” czy „Jesień2020!”. Dodatkowo kwestia zapamiętywania starych haseł jest o tyle istotna, że w przypadku, gdy użytkownik popełni jeden z kardynalnych błędów w kwestii haseł – zastosuje to samo hasło do wielu różnych usług/serwisów (co powiedzmy sobie szczerze, jest nagminną praktyką), a hasła z któregoś z tych serwisów wyciekną, mamy zdecydowanie większe prawdopodobieństwo, że użytkownik nie wrócił do swojego starego hasła, które może być już znane atakującym. Minimalna ilość zapamiętywanych haseł jest w mojej opinii uzależniona od częstotliwości, z jaką wymuszamy użytkownikowi zmianę hasła, tak by ograniczyć możliwość stosowania nazw miesięcy czy pory roku. Czysto teoretycznie, dla zmiany hasła wymuszanej co miesiąc absolutnym minimum wydaje się być zapamiętywanie 13 ostatnich haseł (warto wziąć dodatkowo po uwagę częstotliwość wymuszania zmiany hasła o czym niżej):

• Maximum password age – to ustawienie określa częstotliwość, z jaką użytkownik będzie zmuszony zmienić hasło. Domyślnie wartość tego pola ustawiona jest na 42 dni – oznacza to, że 43 dni od dnia utworzenia hasła użytkownik po zalogowaniu otrzyma od razu komunikat o konieczności zmiany hasła i przed ukończeniem tego procesu nie będzie mógł dostać się do systemu. Częstotliwość zmiany hasła jest bardzo istotną kwestią z punktu widzenia bezpieczeństwa. Sam fakt konieczności wymuszania zmiany hasła wynika z wspomnianego przy opisywaniu poprzedniej opcji zagrożenia, wynikającego z stosowania tego samego hasła do wielu systemów, gdzie każdy wyciek z dowolnego jednego serwisu może ujawnić hasło przypisane do innych kont tego samego użytkownika. Zwyczajowo przyjmuje się, że wymuszanie zmiany hasła powinno przebiegać co 30-90 dni. Częstotliwość zmiany warto rozważyć na podstawie wymuszanej złożoności hasła. Wymuszanie tworzenia długich i trudnych haseł połączone ze zbyt częstym wymuszaniem zmiany spowoduje u użytkowników zapisywanie takich haseł na słynnych żółtych karteczkach przylepionych do laptopa czy monitora – w efekcie poziom bezpieczeństwa istotnie się zmniejszy, zamiast się zwiększyć. Środkowa wartość, 60 dni, wydaje się w mojej opinii optymalną wartością.

• Minimum password age – opcja określające ile czasu musi minąć pomiędzy dwoma zmianami hasła. Domyślna wartość 1 dnia wydaje się wystarczającym rozwiązaniem, choć jest to uzależnione od częstotliwości wymuszania zmiany hasła oraz liczby zapamiętywanych haseł w historii. Ograniczenie możliwości zmiany hasła przez 1 dzień po jego zmianie uniemożliwia oszukanie innych opcji, np. tej przechowującej historię haseł. Ambitny użytkownik, któremu nie ograniczymy możliwości zmiany hasła, szczególnie w przypadku, gdy historia haseł byłaby stosunkowo mała, mógłby wielokrotnie zmieniać hasło, tak by móc z powrotem wrócić do wykorzystywanego przez niego wcześniej hasła. W ten sposób zabezpieczenie w postaci historii haseł byłoby zupełnie nieefektywne. Ustawienie zbyt długiego okresu pomiędzy zmianami haseł w mojej opinii jest całkowicie nietrafionym pomysłem – użytkownik będąc świadomym wycieku swojego hasła nie może być pozbawiony możliwości jego szybkiej zmiany. Przy ustawieniu minimalnego wieku hasła na 1 dzień istnieje znikome prawdopodobieństwo, że takie hasło wycieknie i użytkownik zdąży się o tym dowiedzieć w ciągu 24h:

• Minimum password length – ustawienie określające minimalną dopuszczalną długość hasła, które musi utworzyć użytkownik. Minimalnym wymaganiem bezpiecznego hasła jest zastosowanie przynajmniej 8 znaków. Uważam jednak, że tą wartość można spokojnie podnieść do 10-12 znaków bez istotnie dużego wpływu na trudność w zapamiętaniu hasła. Szczególnie w przypadku kluczowych dla kont taki limit powinien zostać znacznie podniesiony – nawet do 15-16 znaków, jeżeli przejęcie dostępu do takiego konta wiąże się z uzyskaniem bardzo szerokich uprawnień przez atakującego. Więcej na temat istoty długości haseł opisywałem tutaj:

• Password must meet complexity requirements – opcja wymuszająca zastosowanie minimalnych wymagań co do złożoności hasła, tj. wymuszenie wystąpienia w haśle znaków z przynajmniej 3 z 4 grup (małych i dużych liter, cyfr, znaków specjalnych). Ten temat oraz jego wpływ na siłę hasła również został opisany w tym wpisie. Ciężko jest mi wyobrazić sobie sytuację, w której ta opcja powinna zostać ustawiona na Disabled:

• Store passwords using reversible encryption – opcja utrzymywana ze względu na kompatybilność wsteczną, która powoduje szyfrowanie przechowywanych haseł tak, aby było możliwe ich odszyfrowanie. Niektóre aplikacje mogą do swojego działania wymagać hasła danego użytkownika i jest to w zasadzie jedyne znane mi zastosowanie dla tej opcji. Jeżeli nie jesteśmy w 100% pewni, że ustawienie jej na „Enabled” jest niezbędne w danym przypadku (a jeżeli już, to stosujmy to w jak najwęższym zakresie), opcja ta powinna być zawsze wyłączona aby utrudnić atakującemu dobranie się do haseł do kont użytkowników w danej domenie.

Opisane powyżej ustawienia pozwalają na zdefiniowanie podstawowych wymagań dotyczących haseł, jednak nie wyczerpują tematu. Przy okazji konfigurowania wymagań haseł do kont użytkowników warto zajrzeć również do zakładki Account Lockout Policy:

Znajdziemy tutaj 3 możliwe do skonfigurowania opcje:

• Account lockout threshold – jako najważniejszą spośród trzech, określającą po ilu nieudanych próbach logowania możliwość podjęcia kolejnych prób ma zostać czasowo zablokowana. Ustawienie tej opcji zabezpiecza nas przed próbą odgadnięcia hasła do konta danego użytkownika za pomocą np. metody brute-force (nie jest to swoją drogą jedyne zabezpieczenie. System Windows ma wbudowany szereg innych zabezpieczeń przed próbami siłowego złamania hasła, np. wyświetlanie przez dłuższy okres czasu napisu „Zapraszamy” po kilku nieudanych próbach logowania, mimo, że logowanie nie przebiegło pomyślnie, co ma spowolnić proces złamania takiego hasła).
• Account lockout duration – opcja określająca czas trwania blokady, uniemożliwiającej podjęcie próby logowania po osiągnięciu wskazanej w poprzednim logowaniu liczby nieudanych logowań
• Reset account lockout counter after – opcja określająca czas, po jakim licznik nieudanych prób logowania ma zostać zresetowany

Przykładowa finalna konfiguracja może wyglądać następująco:

Przy takich ustawieniach po 3 nieudanych próbach logowania (2 dozwolone próby, stąd wartość ustawiona na „2”) przez 30 minut od ostatniego logowania użytkownik nie będzie mógł podjąć kolejnej próby – zostanie mu wyświetlony następujący komunikat:

Na koniec warto jeszcze wspomnieć o opcji pozwalającej na zdefiniowanie czasu wyświetlania komunikatu o zbliżającej się konieczności zmiany hasła. Umożliwia nam to opcja Interactive logon: Prompt user before password expiration znajdująca się w następującym miejscu:

W zależności od ustalonej wartości, użytkownik będzie powiadamiany o zbliżającej się konieczności zmiany hasła ustaloną liczbę dni wcześniej. Opcja jest bardzo prosta w konfiguracji oraz w działaniu, a przypominając użytkownikowi o konieczności zmiany hasła odpowiednio wcześniej, pozwala mu na dokonanie tego w dogodnym dla niego momencie przed upływem terminu ważności hasła.

I to w zasadzie tyle jeżeli chodzi o konfigurację podstawowych ustawień w GPO dotyczących haseł, czy mówiąc szczerze logowania użytkownika do swojego komputera. Kluczową kwestią przy ich konfiguracji będzie realne spojrzenie na to, na ile restrykcyjne ustawienia jesteśmy w stanie wdrożyć – będąc gotowym na użytkowników wyrażających swoje niezadowolenie z konieczności regularnej zmiany hasła czy wymyślania hasła o odpowiedniej złożoności. Istotą problemu będzie znalezienie odpowiedniego balansu między bezpieczeństwem, a możliwością przystosowania się do zasad – inaczej nasze bezpieczeństwo runie za sprawą legendarnych już żółtych karteczek z zapisanymi hasłami.

Mimo, iż nie jesteśmy w stanie wymusić na użytkownikach tworzenia realnie silnych, niesłownikowych haseł, musimy inwestować w ich edukację w tym zakresie. Jeżeli nie są oni zainteresowani – zmień metodę, postaraj się do nich dotrzeć. Nie wolno nam zaniechać prób dotarcia do świadomości użytkowników w tym zakresie, bo pomimo najlepszych zabezpieczeń i najbardziej „opornego na wiedzę z zakresu bezpieczeństwa materiału” na koniec dnia poziom bezpieczeństwa całej organizacji zależy w dużej mierze od świadomości użytkowników w tym zakresie.

Coś jest dla Ciebie niezrozumiałe? Chciałbyś wyrazić opinię na temat artykułu? Znalazłeś jakiś błąd? Koniecznie daj mi o tym znać wysyłając maila lub wypełniając formularz!