Polityka haseł a RODO.

Polityka haseł a RODO.

Od 2004 roku obowiązywał ściśle określony standard, jakie musiały spełniać hasła do systemów informatycznych, służących do przetwarzania danych osobowych. W rozporządzeniu do uchylonej już ustawy o ochronie danych osobowych wskazano wprost, że hasło musi składać się z co najmniej 8 znaków, zawierać małe i wielkie litery oraz cyfry lub znaki specjalne. Hasło należało też  zmieniać nie rzadziej, niż co 30 dni. Od 25 maja 2018 tak szczegółowe przepisy już jednak nie obowiązują.

Szczegółowych wskazań nie znajdziemy więc już w przepisach – zasady, jakie przyjąć przy nadawaniu użytkownikom haseł każdy administrator musi przyjąć samodzielnie – teoretycznie, w praktyce należy opierać się na aktualnych standardach wynikających z powszechnie uznawanych norm technologicznych. Innymi słowy jedynie opierając się na zasadach wynikających z aktualnego poziomu wiedzy administrator może wykazać, że środki organizacyjne i techniczne które zastosował są odpowiednie (a to właśnie za brak odpowiedniości może być nałożona kara pieniężna).

W głośnej decyzji, którą nałożono blisko 3 miliony złotych kary pieniężnej na Morele.net Prezes Urzędu Ochrony Danych rozliczał ukaranego administratora danych z przestrzegania standardów opisanych w wytycznych jednej z amerykańskich agencji federalnych – NIST (National Institute of Standards and Technology) a dokładniej zawartych w dokumencie – „NIST 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management. Przyjrzyjmy się zatem, jak w tym dokumencie odniesiono się do zasad, jakie powinny spełniać hasła do systemów informatycznych.

(*wytyczne używają w specyficzny sposób sformułowań takich jak „SHALL”/SHALL NOT = musi/nie może oraz SHOULD/SHOULD NOT = powinien/nie powinien)

  • Administrator nie powinien ustalać odgórnie terminów, po których upływie wymagana będzie zmiana hasła.

Chodzi zarówno o wymuszanie zmiany haseł środkami technicznymi (np. ustalanie daty ważności, wygaśnięcia hasła) jak i organizacyjnymi np. wymaganie od pracownika by podpisał oświadczenie zawierające zobowiązanie do zmiany hasła co 30/60/90 dni.

Wynika to wprost z  akapitu 9 rozdziału 5.1.1.2 wspomnianych wytycznych:

„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.”

Powód do takiego zalecenia jest prosty – użytkownik instynktownie będzie stosował słabsze hasła, mając świadomość tego, że i tak za krótki okres będzie musiał je zmienić.  Z dotychczasowej praktyki wynika, że przy takiej wymuszonej, okresowej zmianie użytkownik najczęściej stosuje hasło podobne, z dodaniem np. kolejnego numeru (1, 2, 3 itd.).

Stwarza to fałszywe poczucie bezpieczeństwa, ewentualny atakujący również jest świadomy tego, w jaki sposób najczęściej użytkownicy postępują przy zmianie haseł. Wspomniane wytyczne zalecają natomiast tzw. „event-based change” co oznacza, że administrator powinien wymusić zmianę haseł jeżeli powziął uzasadnione podejrzenie, że doszło do naruszenia poufności – powinno się dziać wyłącznie na zasadzie wyjątku. Rzadkie wymuszanie zmiany haseł motywuje użytkownika do tego, by stosować trudniejsze hasło.

  • Administrator nie powinien stosować wymuszania stosowania specjalnych znaków, symboli lub cyfr.

Chodzi o zasadę, która od 2004 do 2018 roku obowiązywała w polskim systemie prawnym: „małe i wielkie litery oraz cyfry lub znaki specjalne”, wprost wynika to z tego samego akapitu wspomnianych wytycznych:

„Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.”

Argumentowane jest to tym, że taki rodzaj wymuszania najczęściej prowadzić np. do prostego dodania „!” do stosowanego hasła lub innych przewidywalnych zachowań np. posłużenia się pierwsza literą jako wielką. Dodatkowo, wskazuje się, że mechanizm ten prowadzi do frustracji użytkownika co z kolei skutkuje skupieniem się nie na rzeczywistej trudności hasła, a jedynie na tym, by jak najszybciej uporać się z przeszkodą co prowadzi właśnie do powtarzalnych, przewidywalnych zachować, jak wskazano powyżej – co więcej, prowadzi to także do stosowania w wielu miejscach jednego hasła (skoro trudno je zapamiętać) lub zapisywania ich w widocznych miejscach.

Wytyczne zalecają zamiast wymuszania znaków specjalnych stosowanie czarnych list haseł (najprostszych lub najczęściej stosowanych), takich jak np. „123456”, „hasło1”, „qwerty” itd.

  • Administrator powinien umożliwić wykorzystywanie komendy „wklej” przy wpisywaniu hasła – tak, by umożliwić użytkownikowi stosowanie menadżera haseł (jeżeli użytkownik uzna to za odpowiednie).

Jak wprost wskazuje się w akapicie 10 przytaczanego rozdziału wspominanych wytycznych NIST:

„Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.”

  • Przy konstruowaniu polityki haseł należy zachęcać użytkowników do tworzenia maksymalnie długich haseł.

Załącznik A do wspomnianych wytycznych:

„Password length has been found to be a primary factor in characterizing password strength. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.”

  • Administrator powinien ustalić limit nieudanych logowań po którym dojdzie do resetowania hasła (maksymalnie 100 nieudanych logowań).

Rozdział 5.2.2. wspominanych wytycznych NIST:

„(…)verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.”

  • Zaleca się, by administrator stosował wskaźniki „mocy” hasła „password-strength metres”.

Akapit 7 przytaczanego rozdziału wspominanych wytycznych NIST:

„Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meters, to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets (Blacklists).”

To tylko niektóre z przytaczanych zaleceń – biorąc pod uwagę że obowiązujące przez wiele lat poprzednie przepisy mogą być źródłem wielu (niekoniecznie zgodnych z obecnym poziomem wiedzy) nawyków  – warto sprawdzić w swojej organizacji dotychczasową politykę haseł w kontekście przytaczanych wytycznych.

Dodaj komentarz