Współczesne podejście do polityki haseł odchodzi od dawnej praktyki wymuszania zmiany co stały okres (np. 30 lub 90 dni). Powód jest praktyczny: gdy użytkownicy muszą często zmieniać hasło, zwykle tworzą przewidywalne modyfikacje poprzedniego (np. dopisują cyfrę lub miesiąc) albo zapisują je w niebezpieczny sposób. W efekcie realne bezpieczeństwo spada, mimo że "polityka" wygląda na restrykcyjną.
Poprawna odpowiedź brzmi: "tylko w przypadku podejrzenia naruszenia bezpieczeństwa." Hasło powinno być zmienione wtedy, gdy pojawia się przesłanka, że ktoś mógł je poznać lub konto mogło zostać przejęte: po informacji o wycieku, po zauważeniu nietypowych logowań, po podejrzeniu złośliwego oprogramowania, albo gdy użytkownik sam ujawnił hasło.
Dlaczego pozostałe odpowiedzi są nieprawidłowe?
- "co 90 dni wraz z wymogiem użycia znaków specjalnych." – stały termin zmiany jest właśnie tym, od czego odchodzi się w aktualnych zaleceniach. Dodatkowo sztywne reguły "złożoności" mogą prowadzić do przewidywalnych schematów, zamiast promować długie i unikalne hasła.
- "co 30 dni na podstawie ISO 27001." – ta odpowiedź sugeruje konkretny okres jako standard. Z perspektywy aktualnych zaleceń bezpieczeństwa kluczowe jest zdarzenie ryzyka (kompromitacja), a nie kalendarzowa rotacja.
- "zawsze po urlopie lub dłuższej nieobecności." – nieobecność sama w sobie nie oznacza, że hasło zostało ujawnione. Zmiana po urlopie może być procedurą organizacyjną, ale nie jest ogólną, nowoczesną zasadą "bezpiecznego hasła".
W praktyce lepiej wymagać długich haseł, blokować hasła popularne/skompromitowane, wspierać menedżery haseł oraz stosować dodatkowe metody uwierzytelniania (np. drugi składnik). Zmianę hasła uruchamia się wtedy, gdy pojawia się realny sygnał ryzyka.
