Polityka haseł to bardzo trudny temat. Każda organizacja ma inne podejście, jak również środki techniczne do zabezpieczenia danych w swoich systemach. Bardzo często jednak spotykam się z czymś, co realnie przynosi więcej szkody niż pożytku - politykami wygasania haseł!
Problem polityk wygasania haseł
Polityka wygasania hasła służy, jak nazwa wskazuje, do systemowego wymuszania zmiany hasła użytkownika po określonej ilości dni od jego ustawienia/ostatniej zmiany. Brzmi kusząco, prawda? Przecież, jeśli Twoje hasło gdzieś wyciekło, to za 30 dni je zmienisz i atakujący nie będzie w stanie go wykorzystać. Brzmi bezpiecznie? Oczywiście, ale dlaczego to ustawienie realnie obniża bezpieczeństwo zamiast je podwyższać?
Bo człowiek jest z natury leniwy 🙂 Zamiast tworzyć za każdym razem unikalne hasła, użytkownicy bardzo szybko będą ustawiać nowe według swoich autorskich schematów i nawyków. Jak wyglądają takie praktyki? Zmiana końcówki obecnego hasła, dopisanie literki bądź cyfry itp. Czy takie hasło jest bezpieczne? Niekoniecznie… Jeśli jesteśmy w stanie odgadnąć następną iterację hasła, to przecież nie gwarantuje nam ono żadnego bezpieczeństwa.
Postawmy się na chwilę na miejscu użytkownika. Jeśli firma ma mnóstwo niezintegrowanych ze sobą systemów, które wymagają korzystania z mnóstwa różnych loginów i haseł, to taka sytuacja wręcz ZACHĘCA użytkownika do kombinowania. Niestety, bardzo często pracownik nie zdaje sobie sprawy, że może się to jednak skończyć tragicznie.
Standardy bezpieczeństwa, a wygasanie haseł
Brzmi sensownie, ale 10 lat temu mieliśmy audyt bezpieczeństwa, który zalecał nam włączenie wygasania haseł, więc coś tu się nie zgadza… Wszystko się zgadza, bo faktycznie 10 lat temu mogliśmy usłyszeć taką rekomendację. Jednak wszystko się zmienia, a polityki i procedury powinny być stale aktualizowane. Czy obecnie znajdziemy w zaleceniach rekomendację stosowania opcji wymuszania wygasania haseł? Sprawdźmy!
Microsoft security baseline
W kontekście domeny Active Directory:
The security baseline recommended by Microsoft doesn’t contain the password-expiration policy, as it is less effective than modern mitigations. However, companies that didn’t implement Azure AD Password Protection, multifactor authentication, or other modern mitigations of password-guessing attacks, should leave this policy in effect.
Dla ciekawskich: w osobnym wpisie wyjaśniłem, czym jest usługa Azure AD Microsoft Entra Password Protection i jak właściwie ona działa.
W kontekście usługi Microsoft 365:
Password expiration requirements do more harm than good, because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous password. Password expiration requirements offer no containment benefits because cybercriminals almost always use credentials as soon as they compromise them.
National Institute of Standards and Technology (NIST)
W publikacji Digital Identity Guidelines Authentication and Lifecycle Management:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
— NIST Special Publication 800-63B - 5.1.1.2 Memorized Secret Verifiers
Center for Internet Security (CIS)
W publikacji CIS Password Policy Guide:
Excessive password expiration requirements do more harm than good,because these requirements make users select predictable passwords, composed of sequential words and numbers that are closely related to each other. In these cases, the next password can be predicted based on the previous one (incrementing a number used in the password for example). Also, password expiration requirements offer no containment benefits because attackers will often use credentials as soon as they compromise them.
Ale żeby nie było, że wycinam tylko wygodne dla siebie fragmenty, to w CIS Password Policy Guide jest również ten zapis:
In addition, we also recommend a yearly password change. This is primarily because for all their good intentions users will share credentials across accounts. Therefore, even if a breach is publicly identified, the user may not see this notification, or forget they have an account on that site. This could leave a shared credential vulnerable indefinitely. Having an organizational policy of a 1-year (annual) password expiration is a reasonable compromise to mitigate this with minimal user burden.
Czyli mówisz, że powinno się wyłączyć wygasanie haseł?
To zależy 🙂
Jeśli w Twojej organizacji stosuje się inne mechanizmy, które chronią przed atakami password guessing to po przeprowadzonej analizie ryzyka być może ułatwisz życie użytkownikom. Natomiast, jeśli dopiero zaczynasz “utwardzanie” haseł, integrację tożsamości i ogólną modernizację infrastruktury, to może warto rozważyć zmianę tego ustawienia na 90 dni lub dłużej?
Generalnie, staraj się unikać niskich wartości tego ustawienia, takich jak zmiana hasła co 30 dni.
Jak wyłączyć wygasanie haseł?
Lokalizacja ustawienia jest zależna od usługi/systemu, z którego korzystasz. Wpis opisuje konfigurację dla usługi Active Directory.
Default Domain Policy
Po utworzeniu nowej domeny Active Directory powstaje domyślna polityka GPO o nazwie “Default Domain Policy”. To właśnie w tym miejscu znajdziemy naszą politykę haseł.
Ścieżka jest trochę podchwytliwa, bo naturalnie szukalibyśmy ustawienia w User Configuration, a tu zaskoczenie, bo ustawienie znajduje się w ustawieniach Computer Configuration.
Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy
Teraz pozostało wprowadzić nową wartość lub wyłączyć ustawienie Maximum password age.
Fine-Grained Password Policy
Utworzenie nowej polityki GPO dla użytkowników w konkretnym OU wydaje się dobrą drogą do zmiany wartości ustawienia Maximum password age. No cóż, wydaje się. Taką politykę oczywiście możemy utworzyć, bo system nam tego nie zabroni, ale czy będzie działać? No właśnie, nie będzie. Zamiast tego należy skorzystać z opcji Fine-Grained Password Policy.
Konfiguracja
Otwieramy Active Directory Administrative Center oraz wybieramy naszą domenę:
Przechodzimy do System > Password Settings Container i wybieramy New > Password Settings
Tworzymy nową dedykowaną politykę haseł oraz wybieramy docelowych użytkowników lub grupę security.
Gotowe. Po utworzeniu powinna pokazać się nam na liście.
Jak zweryfikować, czy polityka działa?
Active Directory Administrative Center
Odnajdujemy naszego użytkownika i wybieramy opcję “View resultant password settings…”. Jeśli użytkownik ma przypisaną politykę, to zobaczymy jej właściwości.
W przypadku, gdy użytkownik nie posiada żadnej polityki Fine-Grained Password Policy, otrzymamy komunikat o braku takiego ustawienia.
PowerShell
Jeśli nie chcemy korzystać z Active Directory Administrative Center, to możemy wykorzystać PowerShell do weryfikacji ustawień.
| |
Wynik polecenia PRZED zmianą ustawień:
Wynik polecenia PO zmianie ustawień:
Jak widać nasza polityka zadziałała.
Co z Microsoft 365 / Azure AD Entra ID?
Nic… Jeśli mamy AD Connect to domyślnie dla wszystkich zsynchronizowanych kont wygasanie haseł po stronie chmury jest wyłączone. Nasze zmiany w Default Domain Policy lub utworzenie Fine-Grained Password Policy nie ma wpływu na Azure AD Entra ID. Oznacza to, że domyślnie, nawet gdy nasze hasło wygaśnie w on-prem, to wciąż możemy zalogować się do Microsoft 365.
Oczywiście, o ile nie mamy skonfigurowanej polityki Conditional Access, która wymusza pracę na firmowym komputerze, który skomunikuje się z domeną i poprosi o zmianę hasła 🙂
Podsumowanie
Z artykułu właśnie dowiedziałeś/aś się, że stosowanie polityk wygasania haseł, wcale nie zwiększa bezpieczeństwa Twojej firmy, a zazwyczaj działa wręcz odwrotnie niż zakładaliśmy. Jeśli zaciekawił Cię ten temat, to zachęcam Cię do śledzenia tagu Password Policy, na którym będą pojawiać się technologię i narzędzia o podobnej tematyce.