W jaki sposób powinniśmy dbać o jakość haseł tworzonych przez naszych użytkowników? Pewnie większość z Was z pewnością wskazała by tutaj choćby na minimalne wymagania, które musi spełniać bezpieczne hasło czy proste rozwiązania systemowe weryfikujące ich długość czy złożoność. Coraz częściej jednak przyjmujemy podstawowe, wymuszane systemowo wymagania, koncentrując się na adopcji MFA, alternatywnych metod uwierzytelniania, a w co bardziej idealistycznych przypadkach – przygotowaniu do wdrożenia uwierzytelniania typu passwordless. Kierunek ten jest oczywiście całkowicie słuszny – wykorzystanie MFA na bazie odpowiednio bezpiecznych metod uwierzytelniania będzie dużo prostsze i efektywniejsze względem wpływania na jakość haseł.
Nie oznacza to jednak, iż z dbałości o same hasła powinniśmy rezygnować. Hasła były, są i z pewnością przez jeszcze jakiś czas będą najpopularniejszą, najprostszą metodą uwierzytelniania, z której korzystają niemalże wszyscy użytkownicy w zasadzie dowolnych systemów komputerowych. Dlatego też w miarę możliwości powinniśmy zadbać o to, aby bezpieczeństwo tej metody uwierzytelniania było na jak najwyższym poziomie.
W kontekście chmury Microsoftu na wiele aspektów dotyczących bezpieczeństwa haseł nie mamy wpływu. Są jednak mechanizmy, takie jak tytułowy Azure AD Password Protection, które pozwalają nam w istotny sposób podnieść bezpieczeństwo haseł wykorzystywanych przez naszych użytkowników. Jak chmura Microsoft podchodzi o kwestii bezpieczeństwa haseł oraz które aspekty są dla nas konfigurowalne? Zapraszam do lektury!
Czym jest bezpieczne hasło?
Zacznijmy od wyjaśnienia sobie czym w ogóle jest bezpieczne hasło? Najczęściej pojawiające się minimalne wymagania, które musi spełnić hasło przedstawiają się następująco:
- Hasło powinno posiadać minimum 8 znaków (co już w momencie pisania tego artykułu z pewnością jest przestarzałym wymaganiem)
- Hasło powinno zawierać znaki pochodzące z minimum 3, spośród 4 dostępnych grup (małe litery, duże litery, cyfry, znaki specjalne)
- Hasło powinno być niesłownikowe (idealnie – losowy ciąg znaków, nie wyrażenia, które możemy znaleźć w dowolnym słowniku)
- Hasło powinno być unikalne (tj. użytkownik powinien posiadać osobne hasło do każdego systemu, do którego się loguje)
Z czego wynikają takie a nie inne wymagania? Odpowiadając najprościej – z czasu, który musi poświęcić atakujący na ich „złamanie”. Ponad 2 lata temu napisałem na ten temat obszerny artykuł, który wciąż pozostaje aktualny. Jeżeli chcielibyście zrozumieć skąd biorą się takie a nie inne wymagania – zachęcam do jego lektury.
Oczywiście nie na wszystkie aspekty związane z odpowiednią złożonością hasła jesteśmy w stanie wpłynąć systemowo. Na fundamentalne aspekty związane z długością czy wykorzystaniem różnych typów znaków jesteśmy rzecz jasna w stanie wpłynąć już od dawna, co może potwierdzić choćby szybki rzut oka na politykę haseł dostępną dla środowisk on-premisowych w GPO:
Weryfikując i wpływając wyłącznie na te dwa aspekty możemy dojść do sytuacji, iż hasło pomimo ich spełnienia przez cały czas będzie słabe. I nie zrozumcie mnie źle – lepiej wpływać na te dwa aspekty, niż nie wpływać na nie w ogóle (zalecam jednak ustawianie wymagań dla dłuższych haseł niż standardowe 8 znaków z powodów wymienionych w tym artykule). Nie zmienia do jednak faktu, iż hasłem spełniającym standardowo weryfikowane wymagania co do długości i złożoności hasła będzie np.
Kwiatek3
Hasło posiada 8 znaków. Hasło posiada 3 różne typy znaków (duża i mała litera, cyfra). Hasło przejdzie przez wymagania systemowe, a ostatnie co moglibyśmy o nim powiedzieć to, iż jest ono bezpieczne. Dochodzimy więc do miejsca, w którym należy zastanowić się, czy jesteśmy w stanie w jakiś sposób wpłynąć na kwestię „słownikowości” hasła i ograniczyć możliwość wykorzystywania prostych, popularnych słów.
W bardzo ograniczonym zakresie na „słownikowość” mogliśmy wpływać we wspomnianym GPO, gdzie domyślnie zdefiniowana zasada dla odpowiedniej złożoności zabraniała wykorzystania nazwy użytkownika czy części wyświetlanej nazwy użytkownika:
Nie było to jednak możliwe do rozszerzenia czy skonfigurowania w inny sposób. Na szczęście narzędzia chmurowe dają nam o wiele większe możliwości.
Bezpieczeństwo haseł w Azure Active Directory
W nawiązaniu do minimalnych wymagań bezpiecznego hasła na początek warto wspomnieć o tym, iż Azure Active Directory posiada zdefiniowaną i narzucaną z góry politykę określającą minimalne wymagania:
- Hasło powinno posiadać minimum 8 znaków – i, niestety, nie jesteśmy w stanie podnieść tego wymagania. Dla osób korzystających z managerów haseł z pewnością dobrą informacją jest obsługa aż do 256 znaków – kto ustawia długie hasła ten wie jak wiele systemów nie jest choćby przygotowanych na próbę wprowadzenia hasła powyżej 32 czy 64 znaków pod kątem choćby obsługi błędów i pokazania stosownego komunikatu
- Hasło powinno zawierać znaki z przynajmniej 3 grup
- Hasło nie powinno być takie samo jak obecne lub jedno z ostatnio wykorzystywanych – dokładna ilość haseł przechowywanych w historii nie jest określana, jak również, w przeciwieństwie do środowisk on-premises, nie jest możliwa do określenia
- Hasło nie powinno znajdować się na liście zakazanych haseł
I przy ostatnim z punktów dochodzimy do tego, w jaki sposób Azure AD pozwala dbać o jakość haseł w kontekście wyrażeń słownikowych. Hasła są walidowane pod kątem wykorzystania słów, które znajdują się na dwóch listach – globalnej oraz własnej.
Globalna lista zakazanych haseł
Globalna lista zakazanych haseł jest tworzona na bazie telemetrii oraz danych zbieranych przez Microsoft, z których to wyłapywane są hasła, które są słabe, a przy tym często wykorzystywane, jak również hasła, które zostały już złamane (świadomie piszę „złamane” – zgodnie z oficjalnymi informacjami z dokumentacji MS lista nie bazuje na żadnych zewnętrznych źródłach, w tym listach haseł, które znalazły się w wyciekach).
Globalna lista zakazanych haseł, choć z oczywistych względów jest niejawna, jest automatycznie aplikowana do wszystkich kont w Azure Active Directory. Nie można jej wyłączyć, nie można jej konfigurować, nie trzeba jej nigdzie wcześniej włączać. Jej głównym zadaniem jest oczywiście podnoszenie jakości haseł, ale przy tym ograniczenie możliwości wykorzystania ataków typu password spray (atakujący bierze kilka słabych, popularnych haseł i próbuje zalogować się do kolejnych kont użytkowników).
Co istotne – globalna lista haseł nie jest lokalizowana, tj. w przypadku polskich tenantów nie możemy liczyć na listę najczęściej występujących haseł i słów charakterystycznych dla naszego języka. Jest ona obszerna, ale utrzymywana na bazie danych globalnych.
Własna lista zakazanych haseł
Z drugiej strony jest nasza własna lista zakazanych haseł, którą możemy konfigurować we własnym zakresie w ramach tytułowego narzędzia Password Protection. Z założenia nasza własna lista zakazanych haseł powinna zawierać wszelkiego typu nietypowe słowa, związane bezpośrednio z naszą firmą. Może być to np. nazwa firmy, nazwa produktu, lokalizacja oraz wszelkiego typu specyficzne dla firmy wyrażenia, które potencjalnie użytkownicy mogliby zastosować w swoich hasłach.
Jeżeli ktoś z Was pomyślał o tym, iż do tego rozwiązania można zaimplementować cały słownik polskich słów lub pełną listę najpopularniejszych, polskich haseł mam dla Was złą informację – rozwiązanie pozwala na skonfigurowanie maksymalnie 1000 słów. Jednak w ramach 1000 można oczywiście „przemycić” wiele charakterystycznych i często wykorzystywanych w hasłach polskich terminów.
Co bardzo ważne – na liście powinniśmy podawać słowa, nie hasła. Mechanizm weryfikacji bez trudu poradzi sobie z różnego typu formami danego słowa, które możemy spotkać w hasłach. Jak to dokładnie działa? O tym w dalszej części artykułu.
Konfiguracja mechanizmu Password Protection
Zanim zagłębimy się w kwestię tego, w jaki sposób walidowane są hasła, zobaczmy gdzie możemy skonfigurować wspomnianą listę zakazanych haseł oraz jakie jeszcze możliwości oferuje nam ten mechanizm.
W Azure Active Directory odnajdujemy zakładkę Security:
Następnie przechodzimy do Authentication methods:
i wybieramy opcję Password protection:
W tym miejscu odnajdziemy kilka ustawień związanych z bezpieczeństwem uwierzytelniania, w tym wspomnianą listę zakazanych haseł. Sama konfiguracja listy jest niezwykle prosta – włączamy tylko stosowanie wspomnianej listy w polu Enforced custom list i podajemy listę słów oraz wyrażeń, które nie będą mogły być wykorzystywane w hasłach naszych użytkowników (każde słowo od nowej linii):
Jakie jeszcze ustawienia możemy znaleźć w tym miejscu? Opcja Lockout treshold określa liczbę nieudanych logowań, po której konto zostanie czasowo zablokowane (co ma oczywiście na celu spowolnienie ataków typu brute-force:
Lockout duration in seconds określa na jak długo (w sekundach), po przekroczeniu określonego w polu wyżej limitu nieudanych logowań, konto zostanie zablokowane:
Na dole znajdują się również pola, które pozwalają na rozszerzenie ochrony na „lokalne” Active Directory – w przypadku wykorzystywania środowisk hybrydowych:
Wykorzystywanie mechanizmu w środowisku hybrydowym wiąże się oczywiście z dodatkową konfiguracją (niezbędne jest zainstalowanie agenta w środowisku on-prem, postawienia serwerów proxy, aby kontroler domeny nie był wystawiony bezpośrednio do internetu itd.). Przykładowa architektura, która pozwoli na ochronę haseł użytkowników również w lokalnym Active Directory może wyglądać nastepująco:
Z uwagi na brak doświadczenia we wdrażaniu usługi w środowisku hybrydowym – pozwolę sobie na ten moment nie wchodzić głębiej w aspekty konfiguracyjne.
Czy zakazane hasła będą zawsze blokowane?
Definiując własną listę zakazanych haseł jednym z być może nieoczywistych pytań jest to, czy hasła te będą zawsze blokowane? Wydaje się, ze skoro tworzymy listę zakazanych słów, to mechanizm zwyczajnie sprawdzi, czy takie słowo w haśle nie występuje, a o ile występuje – zablokuje próbę ustawienia hasła. Jego działanie jest jednak dużo bardziej złożone, ale przez to też bardziej efektywne.
Posłużmy się więc konkretnym przykładem. Załóżmy, iż na liście zakazanych słów znajduje się słowo „warszawa”. Jak więc zachowa się mechanizm dla kilku przykładowych haseł? Na początek przykładowe hasła, których nie będzie mógł ustawić użytkownik:
W@r5zawa!
W@rszawy
Jak widać drobne zmiany w brzmieniu słowa, zmiany liter na podobne do nich znaki czy cyfry itp. będą wyłapywane i blokowane. Co jednak w przypadku, o ile hasło będzie naprawdę złożone, ale będzie zawierało wyrażenie z listy zakazanych haseł? Np.
3@twarszawa!ghJ
Takie hasło będzie możliwe do ustawienia. Dlaczego tak się dzieje, skoro zawiera ono wyrażenie znajdujące się na liście? Mechanizm zakłada, iż pomimo tego jest ono wystarczająco złożone. W jaki sposób jest to weryfikowane? Tutaj musimy zagłębić się nieco w aspekty techniczne weryfikacji ustawianych przez użytkowników haseł w Azure Active Directory.
Jak Microsoft waliduje hasła?
Użytkownik zmienia, resetuje czy z jakiegokolwiek innego powodu ustawia nowe hasło do swojego konta. W jaki sposób systemy Microsoft weryfikują, czy dane hasło spełnia określone wymagania?
W pierwszej kolejności wpisywane hasło jest oczywiście weryfikowane pod kątem spełniania wymagań stawianych przez politykę bezpieczeństwa – czy jest ono odpowiednio długie, czy wykorzystano przynajmniej 3 rodzaje znaków itd.
Bardziej istotne, przynajmniej w kontekście opisywanego dzisiaj mechanizmu, są kolejne etapy. Po podstawowej weryfikacji przechodzimy do weryfikacji, czy hasło jest zgodne zarówno z globalną jak i własną listą zakazanych haseł. W celu efektywnej weryfikacji wykonywanych jest kilka kroków, które możemy podzielić na dwie sekcje:
Normalizacja hasła
Pierwszym z etapów jest tzw. „normalizacja hasła”. Na tym etapie sprawdzane jest, czy użytkownik nie próbuje zwiększyć bezpieczeństwa hasła min. stosując popularne zamienniki dla niektórych liter. Część cyfr czy znaków jest oczywiście graficznie zbliżona do liter, stąd popularne zamiany:
- A -> @
- A -> 4
- E -> 3
- S -> 5
itd.
Metoda ta z pozoru może wydawać się efektywna w kontekście słownikowych metod łamania haseł. Obecnie jednak narzędzia do tego służące obsługują również wszystkie pupularne zamiany, stąd metoda ta nie jest zbyt efektywna.
Jak jednak przebiega proces normalizacji? Żeby dobrze to zobrazować posłużmy się przykładowym hasłem:
Pierwszy z etapów normalizacji polega na zmniejszeniu wszystkich dużych liter w ustawianym przez użytkownika haśle. Dla przykładowego hasła będzie to wyglądało następująco:
Następnie, w kolejnym etapie normalizacji typowe znaki czy cyfry są zamieniane na odpowiadające im litery. Proces dla przykładowego hasła wygląda nastepująco:
Dopiero na tym etapie efekt normalizacji jest porównywany zarówno z Globalną jak i Własną listą zakazanych haseł. Dzięki temu ustawienie na liście jednego słowa „warszawa” pozwala zablokować wiele różnych prób czy modyfikacji użytkowników, którzy próbowaliby ustawić tego typu wyrażenie w swoim haśle. Jak jednak wygląda sam proces weryfikacji, czy znormalizowane już hasło jest zgodne z zasadami w kontekście list zakazanych haseł?
Czy hasło może zostać ustawione?
Etap weryfikacji hasła, który następuje po jego normalizacji możemy podzielić na 3 kroki.
W pierwszym z nich mechanizm weryfikuje, czy znormalizowane hasło nie zawiera się na którejś z list zakazanych haseł obsługując przy tym drobne modyfikacje. Posługując się przez cały czas przykładowym hasłem mechanizm wykryje i zablokuje utworzenie takiego hasła jeżeli:
- do hasła zostanie dopisany 1 znak
- znalezione wyrażenie nie będzie zawierało jednego znaku
- jeden ze znaków w słowie zostanie zamieniony na inny
W ten sposób drobne modyfikacje wprowadzane w zakazanym haśle również nie będą możliwe.
W kolejnym kroku nastąpi weryfikacja, która będzie miała na celu wyłapanie, czy w haśle nie występują wyrażenia typu Imię, Nazwisko użytkownika czy nazwa tenanta. Krok ten być może nie jest bezpośrednio związany z listą zakazanych haseł, ale automatycznie wyklucza możliwość osłabienia tworzonego hasła poprzez wykorzystanie łatwych do odgadnięcia, a często widocznych przy logowaniu (np. w mailu) „atrybutów” danego użytkownika. W moim przypadku hasłem, które zostało by zablokowane będzie np.
W ostatnim kroku następuje chyba najważniejsza dla decyzji weryfikacja, która ma na celu określenie, czy hasło jest odpowiednio złożone i może być wykorzystane, choćby o ile zawiera ono słowa z listy zakazanych haseł. Co dzieje się na tym etapie?
Znormalizowane hasło jest oceniane poprzez prostą punktację:
- 1 pkt za każde znalezione w haśle wyrażenie, które pochodzi z globalnej lub własnej listy zakazanych haseł
- 1 pkt za każdy znak, który nie należy do wyrażenia pochodzącego z globalnej lub własnej listy zakazanych haseł
Jeżeli hasło w sumie zostanie ocenione na 5 pkt (lub więcej) – może zostać ustawione przez użytkownika.
Żeby lepiej to zobrazować załóżmy, iż na własnej liście zakazanych haseł mamy wyrażenie „warszawa”, a na globalnej liście znalazło się słowo „password”. Przykładowe hasło, które ustawił użytkownik to np. „warszawa!password!”. Jak wygląda ocena takiego hasła:
- Słowo „warszawa” znajduje się na własnej liście zakazanych haseł, więc za jego użycie hasło otrzymuje 1 pkt
- Znak „!” otrzymuje 1 pkt, ponieważ nie jest częścią żadnego ze słów z list zakazanych haseł
- Słowo „password” znajduje się na globalnej liście haseł, więc otrzymuje 1 pkt
- Ponownie znak „!” nie jest częścią żadnego ze słów, więc otrzymuje 1 pkt
W sumie tak skonstruowane hasło zostanie ocenione przez system na 4 pkt. Nie spełnia ono wymogu min. 5 pkt, więc system nie pozwoli użytkownikowi na ustawienie takiego hasła.
Spójrzmy teraz na inny przykład:
Takie hasło zawiera zakazane wyrażenie „warszawa”, za co hasło otrzyma 1 pkt, ale oprócz tego posiada również 4 inne znaki, które nie są z nim związane, każdy wart 1 pkt. Łącznie więc przedstawione powyżej hasło otrzyma ocenę 5 pkt, co oznacza, iż pomimo wykorzystania w haśle wyrażenia z listy zakazanych haseł użytkownik będzie mógł je ustawić, ze względu na nieco większą złożoność.
Blokada hasła z perspektywy użytkownika
Ostatnią rzeczą, na którą warto zwrócić uwagę w kontekście haseł jest perspektywa użytkownika. Co stanie się, o ile użytkownik będzie próbował ustawić hasło zawierające słowo z listy zakazanych haseł, a przy tym nie spełniające wyżej opisywanych wymagań?
System wskazuje użytkownikowi jasno, iż hasło zostało odrzucone ze względu na wykorzystanie wyrażenia wyrażenia, które jest zabronione przez organizację.
