Kilka dni temu opublikowaliśmy wpis Czy sprawdzanie cudzych adresów e-mail w bazach wycieków narusza prywatność? W dzisiejszym wpisie poruszamy podobny problem.
Na pierwszy rzut oka pomysł brzmi skrajnie. Pracodawca bierze hasła pracowników i sprawdza je w bazie pochodzącej z cyberataków. Czy to nie jest właśnie coś, przed czym powinien ludzi chronić?
Problem znika, gdy rozróżnimy dwie zupełnie odmienne praktyki. Jedna polegałaby na żądaniu od pracowników podania prywatnych haseł. Druga – na automatycznym sprawdzaniu, czy hasło ustawiane do firmowego systemu znajduje się na liście znanych skompromitowanych wartości. To drugie jest obecnie uznawaną praktyką bezpieczeństwa.
NIST wręcz zaleca blokowanie skompromitowanych haseł
Aktualne wytyczne NIST przewidują, że przy ustanawianiu lub zmianie hasła system powinien porównywać proponowany sekret z listą wartości powszechnie używanych, przewidywalnych albo wcześniej skompromitowanych. Jeżeli hasło znajduje się na takiej liście, użytkownik powinien wybrać inne.
To bardzo różni się od starego modelu „minimum osiem znaków, wielka litera, znak specjalny i zmiana co 30 dni”. NIST odchodzi od obowiązkowych, sztucznych reguł złożoności i kładzie nacisk m.in. na długość oraz unikanie haseł, które już wcześniej pojawiły się w wyciekach.
Nie trzeba wysyłać hasła do HIBP
Pwned Passwords wykorzystuje mechanizm k-anonimowości. Hasło jest lokalnie hashowane, a do usługi trafia tylko pierwszych pięć znaków skrótu. HIBP zwraca zestaw pasujących sufiksów, a pełne porównanie odbywa się po stronie użytkownika.
Dzięki temu firma może wdrożyć kontrolę skompromitowanych haseł bez przesyłania do zewnętrznego serwisu pełnego hasła pracownika ani jego kompletnego hash-a.
Czego pracodawca nie powinien robić
Zupełnie inną sytuacją byłoby poproszenie pracowników o podanie haseł do prywatnej poczty, Facebooka czy banku „w celu sprawdzenia bezpieczeństwa”. Taka praktyka byłaby nie tylko ogromnym ryzykiem, lecz również naruszałaby podstawową zasadę, że hasło powinno pozostawać sekretem użytkownika.
Równie niebezpieczne byłoby przechowywanie firmowych haseł w postaci jawnej tylko po to, aby okresowo wysyłać je do zewnętrznej usługi. Bezpieczeństwo haseł wymaga właśnie tego, aby system sam nie znał i nie przechowywał ich w odwracalnej formie.
Można sprawdzać bezpieczeństwo bez podglądania sekretów
To najważniejszy wniosek. Dobrze zaprojektowany system nie potrzebuje wiedzieć, że pracownik używa hasła SuperTajneHaslo123. Potrzebuje jedynie ustalić, czy jego reprezentacja odpowiada wartości znajdującej się na liście skompromitowanych sekretów.
Kontrola haseł z wycieków jest sensownym mechanizmem bezpieczeństwa właśnie wtedy, gdy została zaprojektowana tak, aby pracodawca nie poznawał haseł swoich ludzi. To drobna techniczna różnica, ale ogromna różnica dla prywatności.