Wreszcie okres ważności hasła (potocznie odbierany jako częstotliwość zmiany hasła) nie zależy od przepisów. Dla niewtajemniczonych – kiedyś była taka Ustawa o ochronie danych osobowych, która wobec hasła praktycznie nakazywała „… zmiana następuje nie rzadziej niż co 30 dni”.

Obecnie okres ważności hasła może być wyznaczany indywidualnie przez każdą firmę/organizację, bazując na analizie ryzyka. Co więcej, możliwe jest wyznaczenie różnych okresów ważności hasła dla poszczególnych zastosowań, np. uwierzytelnianie do systemów informatycznych, zabezpieczanie hasłem plików, itp.. Niemniej, zawsze trzeba zrobić analizę ryzyka i co najważniejsze udokumentować jej przeprowadzenie, ponieważ:

1. ktoś musi zatwierdzić decyzję o okresie ważności hasła i najlepiej by miał udokumentowane podstawy decyzji;
2. posiadanie dowodów wykonania analizy ryzyka ułatwia przechodzenie audytów;
3. gdyby jednak doszło do incydentu bezpieczeństwa związanego z hasłem, to może przyjść kontrola „ważnej instytucji”, a wtedy udokumentowana analiza ryzyka bardzo ułatwi przejście kontroli.

Okres ważności hasła jest wprost zależny od długości zastosowanego hasła i jego złożoności. Ryzyko stosowania hasła musimy szacować z uwzględnieniem wszystkich cech łącznie, biorąc pod uwagę kontekst użycia.

Niniejszy wpis skupia się na okresie ważności hasła. W kolejnym wpisie przedstawię podejście do oszacowania ryzyka hasła biorąc pod uwagę wszystkie cechy oraz kontekst użycia.

Okres ważności hasła (i konieczność zmiany hasła) wynika z:

1. hasła mogą być łamane (odgadnięte, odszyfrowane) – okres ważności hasła powinien być na tyle krótki, by prawdopodobieństwo złamania dostępnymi dla atakujących metodami (obecnie i w okresie obowiązywania polityki haseł) było akceptowalnie niskie.
2. w przypadku gdyby doszło do złamania hasła (np. podejrzenie wypisywania hasła przez użytkownika, czy wykorzystanie key logger’a), to po upłynięciu okresu ważności hasła atakujący utraci dostęp (do systemu), który uzyskał dzięki złamaniu hasła.

Z perspektywy wygody użytkowników, chcielibyśmy by okres ważności hasła był możliwie długi.

1. Częsta zmiana hasła powoduje minimalną zmienność kolejnych haseł – zazwyczaj tylko jeden znak co w przypadku kompromitacji hasła, nawet po jego zmianie – odgadnięcie nowego hasła nie stanowi znacznego problemu.
2. Częsta zmiana hasła powoduje, że użytkownicy stosują identyczne hasła w różnych systemach – przełamanie hasła w jednym z systemów (najsłabiej zabezpieczonym) może otworzyć drogę do kolejnych.
3. Częsta zmiana hasła powoduje konieczność zapamiętywania kolejnych haseł, co może powodować po stronie użytkowników zapisywanie haseł w pobliżu miejsca pracy.
4. Rzadko zmieniane hasła w przypadku kompromitacji dają atakującemu szansę na długotrwały dostęp do systemu.

Czynniki wpływające na okres ważności hasła:

1. Potencjalny czas łamania hasła, na który bezpośredni wpływ maja jego długość i skomplikowanie.
2. Czy próby łamania hasła mogą odbywać się:
   • offline (brak ograniczeń co do prób przełamania hasła, atakujący posiada dostęp do zakodowanego hasła – np. kupił wykradzioną bazę haseł),
   • online (ataki na hasło muszą być wykonywane na funkcjonującym systemie, działa zabezpieczenie blokowania możliwości sprawdzenia hasła po określonej liczbie nieudanych prób).
3. Zastosowane mechanizmy zabezpieczenia hasła takie jak: hash i solenie.
4. Funkcjonuje monitorowanie infrastruktury, które może podpowiedzieć, że hasło jest lub już zostało złamane.

Żeby sobie wyobrazić złożoność czynników hasła, poniżej znajduje się wyliczenie czasu odnalezienia przykładowego hasła w https://www.grc.com/haystack.htm (zrzut ekranu 2018-08-14).

Dla porównania, prostsze ale dłuższe hasło.

Jak łatwo zauważyć – dłuższe hasła, choć znacznie prostsze – bez znaków specjalnych – dużo trudniej poddają się łamaniu.

Przejdźmy do oszacowania ryzyka związanego z wymaganym okresem ważności hasła.

Metoda szacowania ryzyka okresu ważności hasła

Szacowanie ryzyka okresu ważności hasła jest szacowaniem szczegółowym, służącemu podjęciu decyzji odnośnie okresu ważności hasła. W takim przypadku możemy stosować metodę specyficzną, dedykowaną temu konkretnemu zadaniu.

Ryzyko, które będziemy szacowali dotyczy stanu docelowego – czyli szacujemy ryzyko rezydualne (po zastosowaniu wszystkich zabezpieczeń).

Etapy analizy ryzyka:

1. Opisać stan docelowy.
2. Opcjonalnie opisać stan początkowy.
3. Przeprowadzić analizę czynników hasła na co najmniej 3 publicznie dostępnych kalkulatorach jakości hasła, przyjmując przykładowe hasło spełniające minimalne kryteria określone w wariantach.
4. Udokumentować wyniki analizy.
5. Zapisać rekomendację.

Kryteria akceptacji ryzyka:

• Okres łamania hasła dłuższy co najmniej o rząd wielkości od okresu ważności hasła, tj. dla przykładu:
  • dla okresu ważności hasła 1 rok – okres łamania hasła dłuższy niż 10 lat;
  • dla okresu ważności hasła 1 miesiąc – okres łamania hasła dłuższy niż 1 rok.

Przypadek do rozważenia

1. Firma produkcyjna (powiedzmy przetwórstwo spożywcze)
2. Systemy IT wykorzystujące hasło:
   • CRM
   • ERP
   • Księgowość
   • Poczta
   • Publiczna strona WWW z CMS
3. Komputery użytkowników stanowiące cyfrowe stanowisko pracy.

Stan początkowy

• Hasła użytkowników mają ważność 30 dni.

Stan docelowy

Stan docelowy określamy w kilku wariantach i będziemy szacować ryzyko dla poszczególnych wariantów.
Wariant 1:

• Hasła użytkowników mają ważność 60 dni (około 2 miesiące).

Wariant 2:

• Hasła użytkowników mają ważność 90 dni (około 3 miesiące).

Wariant 3:

• Hasła użytkowników mają ważność 180 dni ( około 6 miesięcy).

Wariant 4:

• Hasła użytkowników mają ważność 365 dni (około 12 miesięcy).

Wariant 5:

• Hasła użytkowników nie mają określonej ważność hasła (bezterminowe).

Cechy wspólne wariantów stanu docelowego:

• Hasła muszą mieć minimalną długość 8 znaków.
• Hasła muszą składać się z małych i wielkich liter, cyfr oraz znaków specjalnych.
• Blokowanie konta użytkownika w usłudze katalogowej następuje po 5 nieudanych próbach logowania.
• Użytkownicy logują się do komputerów, korzystają z uwierzytelniania w usługach katalogowych.
• Systemy IT korzystają z SSO (ang. Single Sign On) opartego na usługach katalogowych, co zapewnia pojedynczy login i hasło.
• Usługa katalogowa wymusza zmianę hasła.
• SSO nie funkcjonuje w CMS strony WWW, który ma własną bazę użytkowników i haseł.
• Procedura obsługi CMS nakazuje zmieniać hasło nie rzadziej niż co 90 dni.
• Blokowanie konta użytkownika w CMS następuje po 5 nieudanych próbach logowania.
• Polityka hasła nakazuje użytkownikom stosowanie różnych haseł.

Dla uproszczenia analizy, w niniejszym wpisie skupimy się jedynie na analizie ryzyka okresu ważności hasła użytkowników. Przyjmiemy również, że pozostałe cechy hasła, takie jak jego minimalna długość i złożoność będą identyczne z wcześniejszymi praktykami w tym zakresie.

Analiza czynników hasła przy wykorzystaniu kalkulatorów jakości hasła

Przykładowe hasło poddawane analizie: d$2E#L4e

Wyniki (uzyskane 2018-08-23):

Tabela pokazuje smutną prawdę – ośmio-znakowe hasło poddaje się dość szybko. Trzeba tu jeszcze pamiętać, że to maksymalny czas łamania hasła – czyli przeszukania wszystkich kombinacji :(.

Na ten moment okres ważności hasła należałoby raczej skrócić.

Ale, na szczęście to nie koniec analizy ryzyka. W tym miejscu dla okresu ważności hasła bierzemy jeszcze dwa aspekty

1. potencjalną możliwość wykradzenia bazy haseł w postaci skrótu (upewniamy się, że hasło nie jest w żadnym przypadku przechowywane w postaci jawnej)
2. liczba możliwych prób uwierzytelnienia przed zablokowaniem konta.

W badanym przypadku mamy realnie 2 bazy haseł użytkowników:

1. hasła użytkowników w usłudze katalogowej
2. hasła użytkowników w bazie systemu CMS

Przyjmujemy, że:

• oba systemy mają zaimplementowane zabezpieczenie blokowania konta użytkownika, po 5 nieudanych próbach uwierzytelnienia;
• wykradzenie bazy haseł użytkowników z usługi katalogowej praktycznie nie jest możliwe z uwagi na konstrukcje zabezpieczeń systemu, natomiast baza haseł użytkowników systemu CMS mimo że jest zabezpieczona, to prawdopodobieństwo błędów konfiguracji systemu jest większe i możliwe jest wykradzenie bazy haseł.

Te zabezpieczenia mają kolosalny wpływ na możliwość zmiany okresu ważności hasła, ponieważ:

• w przypadku dostępu atakującego do zaszyfrowanej postaci hasła szybkość sprawdzania kolejnych haseł wynosi – 100 miliardów (100 000 000)/sek, co umożliwi złamanie hasła po około 18.62 godz.
• gdy atakujący nie ma dostępu do zaszyfrowanej postaci hasła i musi ograniczyć liczbę prób do 4 na dzień roboczy (zakładamy, że atakujący wykonuje 4 próby odgadnięcia hasła by nie zablokować konta i oczekuje, że prawdziwy użytkownik zaloguje się na początku kolejnego dnia pracy i w ten sposób wyzeruje licznik nieudanych prób uwierzytelnienia) – czas przełamania hasła rośnie do niewyobrażalnych rozmiarów.

Wnioski z analizy dla określonych powyżej waritantów docelowych:

1. Wariant 5 – hasła użytkowników nie mają określonej ważność hasła (bezterminowe) – odrzucamy, ponieważ co prawda potencjalny czas odgadnięcia hasła wykracza poza okresy życia systemów informatycznych, niemniej atakujący może uzyskać dostęp do hasła poprzez np. podejrzenie użytkownika, który wpisuje hasło lub key logger.
2. Dla haseł przechowywanych w usłudze katalogowej – ryzyko jest akceptowalne dla wariant 4 – hasła użytkowników mają ważność 365 dni (około 12 miesięcy) i pozostałych .
3. Dla haseł użytkowników w bazie systemu CMS – z uwagi na możliwość wykradzenia bazy haseł ryzyko pozostaje nieakceptowalne we wszystkich omawianych wariantach.

Teraz policzmy jeszcze wartość ryzyka – posłużymy się podstawową metodą szacowania ryzyka ilościowego.

ALE – annualized loss expectancy – zakładana roczna strata (inaczej potencjalna ilość pieniędzy jakie możemy stracić w ciągu roku)
SLE – single loss expectancy – jednorazowa oczekiwana strata
ARO – annual rate of occurrence – roczny współczynnik wystąpień (inaczej prawdopodobna liczba wystąpień w ciągu roku)
EF – Exposure Factor – współczynnik ekspozycji (inaczej potencjalna strata wartości aktywa wyrażana procentowo)
AV – Asset value – wartość aktywa

ALE = SLE * ARO

SLE = EF * AV

AV = 100 000,00 zł – oszacowana maksymalna wartość danych firmowych chronionych hasłem
EF = 50% – utrata wartości danych w przypadku straty poufności haseł użytkowników
ARO = 0,05 – przyjmujemy, że udany atak na hasło w firmach branży spożywczej występuje 1 raz na 20 lat

SLE = 50 000,00 zł

ALE = 2 500,00 zł

Zakładana roczna strata wynosi 2 500 zł. Taka wartość ryzyka zostanie przedstawiona Zarządowi firmy celem podjęcia decyzji o akceptacji ryzyka.

Rekomendacje

1. Rekomenduje się ustalenie okresu ważności haseł przechowywanych w usłudze katalogowej na 180 dni (6 miesięcy), dłuższy okres ważności hasła nie jest rekomendowany z uwagi na potencjalną możliwość kompromitacji hasła poprzez podejrzenie użytkownika, który wpisuje hasło lub key logger.
2. Rekomenduje się ustalenie wymogu długości hasła użytkownika systemu CMS do co najmniej 12 znaków i ustalenie okresu ważności haseł przechowywanych w usłudze katalogowej na 180 dni (6 miesięcy).

Dla ryzyka wprowadzone zostają następujące wskaźniki ryzyka (KRI):

1. Liczba zablokowanych kont przez przekroczenie ilości prób z błędnym hasłem.
   • Próg alarmowy – więcej niż 3 konta na tydzień.
2. Częste blokowanie konta określonego użytkownika przez przekroczenie ilości prób z błędnym hasłem.
   • Próg alarmowy – 2 lub więcej zablokowań na miesiąc.
3. Incydenty bezpieczeństwa polegające na kompromitacji hasła (utracie poufności np. poprzez podejrzenie hasła wpisywanego przez użytkownika).
   • Próg alarmowy – każde wystąpienie incydentu.

Konkluzja na podsumowanie

W ryzyku okresu ważności hasła mamy 2 główne przypadki (zakładając, że hasło jest przechowywane w postaci skrótu i spełnia co najmniej wymagania złożoności: duże i małe litery oraz cyfry i znaki specjalne):

1. zabezpieczenia bazy haseł są skuteczne – wykradzenie bazy haseł jest praktycznie niemożliwe i w systemie działa zabezpieczenie blokowania możliwości sprawdzenia hasła po określonej liczbie nieudanych prób – w takim przypadku możemy dopuścić krótkie (8 znakowe) hasła i dłuższy okres ważności hasła (np. 3 miesiące);
2. wykradzenie bazy haseł jest potencjalnie możliwe lub hasło w postaci zakodowanej jest dostępne dla atakującego (np. plik .zip z hasłem – zakodowane hasło jest wewnątrz pliku) – w takim przypadku wymagane są długie hasła – obecnie co najmniej 12 znakowe, by hasło skutecznie chroniło zasoby.

Jeżeli chcielibyśmy zrezygnować z wymuszania złożoności hasła, poza wymuszeniem używania małych liter – wtedy hasło powinno mieć co najmniej 16 znaków.