Paweł Goleń, blog

W dzisiejszym świecie człowiek musi pamiętać wiele haseł (kodów). PIN do komórki, PIN do karty kredytowej/bankomatowej, PIN do alarmu (lub do alarmów), PIN do otwierania furtki na osiedlu albo drzwi na klatkę schodową, hasło do komputera, do poczty, różnych serwisów. Rozwiązania "integrujące" te serwisy (np. OpenID) wciąż są mało popularne. Często stosowanym rozwiązaniem jest używanie wszędzie jednego hasła lub stosowanie haseł z małymi modyfikacjami. To nie jest najlepsze rozwiązanie. Kilka lat temu, gdy Gmail dopiero zaczynał działać, a normalne konta pocztowe miały spore ograniczenia odnośnie wielkości skrzynki, pojawiły się fałszywe "konta pocztowe" o dużej pojemności, gdzie przy zakładaniu konta użytkownik podawał adres obecnego konta (np. po to, by podać link aktywacyjny). Problem w tym, że ci użytkownicy, którzy podali takie samo hasło dla "nowego" konta, jakie mieli na starym, tracili stare konta. O tym, że nikt nowych nie zyskał, chyba nie trzeba mówić?

Trzeba jednocześnie zauważyć, że jest różnica między rozwiązaniem jedno hasło wszędzie, a single sign-on. W rozwiązaniach single sign-on uwierzytelnienie odbywa się odnośnie jednego "głównego serwera", do poszczególnych usług (serwisów) wydawane są natomiast tokeny, które dają dostęp tylko do nich. Przejęcie tokenu do jednego serwisu nie pozwala na dostęp do innego. A przynajmniej tak powinno być, zdarzają się dość spektakularne błędy: Formal Analysis of SAML 2.0 Web Browser Single Sign-On: Breaking the SAML-based Single Sign-On for Google Apps.

W przypadku rozwiązań IdM czasami stosuje się synchronizację haseł między różnymi systemami, by ułatwić użytkownikom życie. Tu różnica jest taka, że środowisko jest kontrolowane (przez firmę), trudniej sobie wyobrazić, by nagle w sieci firmy pojawiła się "wroga" aplikacja biznesowa.

Pisałem o tym kilka razy i powtórzę jeszcze raz - zapisz swoje hasła. Oczywiście nie na żółtej kartce przyklejonej pod klawiaturą. Skorzystać można z narzędzi takich jak Password Minder, KeePass, Password Safe czy innych tego typu. Może to być nawet szyfrowany plik tekstowy.

Większość przeglądarek posiada również narzędzia do zapamiętywania i automatycznego uzupełniania haseł. Korzystanie z nich nie jest najlepszym pomysłem. Choćby dlatego: Google Chrome Receives Lowest Password Security Score.

To taka oczywista oczywistość. Technik jest wiele, ja preferuję passphrase typu K0l3jnyPrzykl@dZl0z0n3g0H@$l@. To dla haseł, które muszę pamiętać. Pozostałych haseł nawet nie znam, generuję je przy użyciu funkcji wbudowanych w wykorzystywane przeze mnie programy (obecnie KeePass). Takie hasła wyglądają mniej więcej tak: BlDXxB6D4$Kn@$0nuJrB. Użycie takich haseł nie jest problemem, jeśli nie trzeba ich pamiętać.

Nie będę tutaj nikogo namawiał do zmiany wszystkich haseł co 30 dni (o ile nie wymaga tego zgodność z przepisami prawa), ale okresowa zmiana haseł jest dobrą praktyką. Hasło bezwzględnie powinno zostać zmienione, jeśli istnieje jakakolwiek szansa, że mogło zostać ujawnione. Ja na przykład zmieniam hasła, jeśli muszę ich użyć na niezaufanym komputerze lub w niezaufanej sieci (lokalnej). Ten drugi przypadek oczywiście odnosi się do tych haseł, które są przesyłane w formie jawnej (jest kilka serwisów, które uporczywie nie korzystają z połączeń SSL).

Problemem może być sytuacja, w której operator serwisu nie informuje jego użytkowników (lub robi to niezbyt skutecznie) o możliwym ujawnieniu haseł... Z tego powodu okresowa zmiana haseł (choć może być uciążliwa), nie jest zła. Pamiętanie o zmianie może wspomagać narzędzie, które jest wykorzystywane do zapisania haseł (większość z nich pozwala na ustawienie "czasu życia" hasła).

To niby też oczywista oczywistość, ale jest problem z łatwowiernością ludzi. Człowiek z natury wierzy w dobre intencje innych osób, w związku z czym w praktyce zasada nie podawania haseł osobom trzecim przybiera formę nie podawaj haseł osobom trzecim, chyba, że o to ładnie poproszą. Wiele osób nie zdaje sobie również sprawy z konsekwencji, jakie mogą je czekać w wyniku ujawnienia swojego hasła.

Użytkownikowi nie można przekazywać sprzecznych informacji. Jeśli kładzie im się do głowy, że haseł nie podaje się osobom trzecim, to (przykładowo) wsparcie informatyczne nie może przychodzić i prosić o hasło użytkownika, bo coś chce sprawdzić/poprawić na jego komputerze. Taka praktyka to powrót do fragmentu ...chyba, że ładnie poprosi z zasady o niepodawaniu hasła osobom trzecim. Później taka osoba jest bardziej podatna na social engineering czy phishing.

To zalecenie dla twórców aplikacji. Jeśli aplikacja musi przechowywać hasła użytkowników (sama realizuje proces ich uwierzytelnienia), nie mogą one być przechowywane w formie jawnej. Powinny one być przechowywane w formie skrótu (hasha). Funkcja wykorzystywana do hashowania haseł powinna być kosztowna obliczeniowo, tak, by spowolnić próby ataku bruteforce. Nie należy wymyślać własnych algorytmów hashowania, lepiej oprzeć się na sprawdzonych rozwiązaniach. Można sobie poczytać choćby opis różnych wersji crypt.