Nie ukrywam, że tytuł tego artykułu jest trochę prowokacyjny, być może nawet clickbaitowy. Ale pełny tytuł, który brzmiałby "O haszowaniu haseł słów kilka, czyli dlaczego nie powinieneś(-naś) podawać swojego hasła, gdy prosi o nie Twój administrator lub dział wsparcia", byłby nie tylko mało atrakcyjny, ale też zwyczajnie nie zmieściłby się na "łamach" blogu. Z drugiej strony, dokładnie opisywałby cel dzisiejszego tekstu, a także zapowiadałby pewien przekaz społeczny. Rzeczywiście, większość z nas wie, że nie wolno podawać swojego hasła konsultantowi czy nawet członkowi działu technicznego i większość domyśla się, dlaczego (a w razie, gdyby jednak nie - chodzi o groźbę utraty konta). Ale nie każdy z nas wie, dlaczego w ogóle ci konsultanci mogą nas o to pytać i to w dobrej wierze. A także dlaczego administratorzy w sumie sami nie odzyskają tej informacji z bazy serwisu.

Jak przechowywane są hasła w systemach informatycznych?

Aby odpowiedzieć sobie na to pytanie, musimy wiedzieć, w jaki sposób hasła są zapisywane w bazie danych, oczywiście, zakładając, że dany serwis uwierzytelnia użytkowników właśnie poprzez podanie takiego "sekretu". Jak się pewnie spodziewacie, nie są one zapisywane w formie jawnej, czyli za pomocą tzw. plain text. Oczywiście, taka forma przechowania danych byłaby najprostsza oraz najszybsza przy sprawdzaniu hasła po wpisaniu go przez użytkownika, jednak nie usprawiedliwia to zagrożenia, które powstaje, gdy do bazy dostanie się nieuprawniona osoba. Wówczas dane do logowania byłyby widoczne jak na dłoni.

Dlatego hasła użytkowników zapisywane w bazie danych muszą być kodowane i tutaj mamy do czynienia z podejściem odwracalnym oraz nieodwracalnym. Pierwsze zakłada, że każde hasło jest transformowane przez pewien algorytm, który zamienia jeden ciąg znaków na inny tak, aby później można było to odwrócić. Przykładem jest słynny szyfr Cezara, który polega na przesunięciu każdego znaku o określoną liczbę. Idąc typ tropem i znając wartość tego przemieszczenia, można odwrócić działanie i poznać oryginalną wiadomość. Z jednej strony jest to lepsze niż plain text, gdyż faktycznie hasła zapisane w systemie są nieczytelne na pierwszy rzut oka. Z drugiej - to zabezpieczenie jest bardzo słabe, gdyż atakujący zacznie szukać w kodzie sposobu obsługi haseł i jeśli znajdzie takie coś, to może zrobić wszystko. Dlatego odwracalną metodę kodowania stosuje się tylko i wyłącznie w przypadku, kiedy jest to naprawdę konieczne, ale może byłoby to 0,01% wszystkich sytuacji.

Dlatego zdecydowanie lepsze jest używanie szyfrowania nieodwracalnego i stosowanie tzw. funkcji skrótu, znanych lepiej pod nazwą funkcji haszujących. Działają one w taki sposób, że pewnej grupie tekstów przydzielają pewien skrót tekstowy. Tego typu algorytmy przydają się przy indeksowaniu danych i przyspieszeniu ich wyszukiwania, jednak nas najbardziej interesuje ich zastosowanie w bezpieczeństwie. Jedną z najprostszych funkcji skrótu jest MD5, który tworzy hasz składający się z liczb szesnastkowych. Przykładowo, ta metoda dla hasła TajneHaslo123 wygeneruje skrót d51472b37f8b58be359ac086c639a7da. Co jednak ważne, mimo że za tym stoi pewien algorytm, to ten kod wygląda na przypadkowy. Na tyle, że dla podobnego hasła TajneHaslo124 hasz to c4eaabcaea5623eceda71955d42943a6, a więc zupełnie inny niż dla poprzedniej danej wejściowej. Co więcej, może istnieć inne hasło, które "przypadkiem" zyskałoby identyczny skrót, co oznacza, że próba rozszyfrowania niezrozumiałego ciągu znaków nic nie da atakującemu. Aczkolwiek uspokajam - szanse, że traficie w dwóch różnych danych na identyczny hasz są dość małe.

Tym niemniej, MD5 jest dość słabym algorytmem do haszowania haseł i zdecydowanie bardziej użyteczny jest w porównywaniu informacji, gdzie zależy nam np. na unikalnym identyfikowaniu obiektów i właśnie ich wyszukiwaniu. Natomiast łamanie haszy zapisanych przez MD5 jest na tyle proste dla obecnych komputerów, że przechowywanie w tej formie danych uwierzytelniających jest bardzo niebezpieczne i niepolecane. Istnieją o wiele lepsze metody typu SHA3 czy bardzo popularny bcrypt. Po użyciu pierwszej (dokładniej w wersji SHA3-256) nasze hasło TajneHaslo123 uzyska skrót:

1da9221b1fbe5a91e90ccd84ff994823c7c4a9d235044a504b5eb1936b0283aa

natomiast po użyciu drugiej:

$2a$13$qxKekEVlvm4ugIbxLK/Jf.JHdUmdHmyZbakTPvER0XokIOmhEG7Rm

A i nie jest to jedyna możliwość ze względu na wiele odmian tej metody oraz użytą "sól" (ang. salt), a więc dodatkowy środek maskujący.

Cechą wspólną takich zabiegów jest fakt, że nie tylko pozwalają one zapisać hasło użytkownika w nieczytelnej formie, ale też nie istnieje algorytm odwracający je do postaci oryginalnej, zwłaszcza, że jako skrót są "urywane" w pewnym momencie. Dotyczy to nie tylko człowieka z "kalkulatorem" i wiedzą o działaniu danej metody, ale też komputera. Proces logowania wygląda zatem tak, że to, co wpisze użytkownik przy wchodzeniu do systemu, jest haszowane, a następnie ten hasz porównywany jest z zapisanym w bazie danych. Jeśli są one zgodne - następuje zalogowanie. Przy czym należy pamiętać, że porównanie nie oznacza całkowitej równości i w zależności od metody może to wyglądać trochę inaczej.

Jak zatem atakujący może uzyskać hasło, skoro nie może go odtworzyć z hasza? Nawet nie próbuje tego robić - zamiast tego może:

• próbować różnych haseł z możliwego zestawu sekretów i liczyć na to, że w końcu trafi (tzw. brute force),
• stosować tzw. tęczowe tablice, który oszczędzają moc obliczeniową i czas oraz wykorzystują powtarzalność haszy,
• próbować uzyskać dostęp do poczty elektronicznej ofiary i zmienić hasło w serwisie,
• zastosować atak socjotechniczny, skłaniając ofiarę do dobrowolnego podania hasła.

Temat jest bardzo szeroki (szczególnie jeśli chodzi o socjotechnikę), jednak nie jest on tematem tego artykułu.

Dlaczego ktoś może chcieć nasze hasło?

Oczywiście, podstawowy powód, który każdemu (słusznie) przyjdzie do głowy, to próba włamania. Świat widział wiele "ataków" polegających na tym, że osoba udająca konsultanta przekonała ofiarę, żeby ta łatwo udostępniła mu dostęp do serwisu. Dlatego praktycznie nigdy nie podawajcie swojego hasła obcej (a nawet i nieobcej) osobie do swojego konta w serwisie. I teraz pora wyjaśnić, dlaczego prawdziwy konsultant lub pracownik działu wsparcia często takich danych nie potrzebuje (prędzej zostaniemy poproszeni telefonicznie o "kod bezpieczeństwa" w celu dalszej rozmowy z help deskiem) lub odwrotnie - kiedy może potrzebować.

Jeśli komunikujemy komuś problem z systemem lub potrzebujemy czegoś od działu wsparcia, to gwarantuję Wam, że specjalista po drugiej stronie - w zależności od poziomu uprawnień i narzędzi - ma możliwość znalezienia Waszych danych nawet bez posiadania hasła. Wynika to oczywiście z dostępu do bazy danych lub specjalnych paneli administracyjnych, które ułatwiają wyszukanie i wyświetlenie pewnych informacji jedynie uprawnionym osobom. Tak naprawdę administratorzy i programiści zazwyczaj, mówiąc m.in. o użytkownikach, posługują się identyfikatorami bazodanowymi, adresami e-mail lub innymi unikalnymi danymi. Oczywiście, z zapewnieniem pełnej dyskrecji i ochrony danych, ale nadal bez dostępu do informacji uwierzytelniających.

Bowiem nawet, gdyby programista czy administrator stanęli na głowie, to nie zobaczą haseł użytkowników w czystej formie. Powodem jest wcześniej omawiane haszowanie i to, że takiego hasza nie można przełożyć na oryginalny kod. Jedyne miejsce, gdzie teoretycznie można zobaczyć przesyłane dane, to podgląd żądań przesyłanych w przeglądarce (tuż po naciśnięciu "Zaloguj się" i podaniu danych) lub w logach serwera. Jednak z pierwszym przypadku ta droga jest (a przynajmniej powinna) być zabezpieczona poprzez protokół HTTPS, a w drugim - takie informacje powinny być wyłączone z zapisywania w logach serwera. To wszystko też wyjaśnia, dlaczego opcja "przypomnij hasło" nie działa tak, że faktycznie przypomina hasło - zamiast tego przesyła nowo wygenerowany tymczasowy kod lub przenosi do formularza zmiany hasła z odpowiednim tokenem (również zabezpieczającym przed złośliwymi agresorami). Jeśli kiedykolwiek serwis w reakcji na użycie opcji "przypomnij hasło" prześle Wam hasło przypominające Wasze, to bardzo polecam przestać korzystać z takiego portalu, gdyż z dużą dozą prawdopodobieństwa Wasze dane uwierzytelniające są w niebezpieczeństwie.

To nie znaczy, że nie ma sytuacji, w której obsługa serwisu nie potrzebuje Waszych haseł. Istnieją bowiem zgłoszenia, których nie sposób odtworzyć inaczej niż logując się na dane konto i mając przed oczami to, co ma użytkownik. Kiedyś na potrzeby takich sytuacji implementowało się dostępny dla administratora przycisk "Zaloguj jako...", który automatycznie pozwalał wejść na konto danej osoby. Jednak to rozwiązanie budzi wątpliwości pod kątem RODO, a ponadto wymaga określonego sposobu obsługi procesu uwierzytelniania, który z kolei jest możliwy przy określonej strukturze aplikacji. Dlatego najczęściej procedura w takich sytuacja wygląda tak, że po uzyskaniu zgody od użytkownika (koniecznie!), obsługa serwisu zamienia hasło na znane tylko sobie po czym prosi o jego ustawienie na nowo lub ewentualnie przywraca poprzedni hasz. Nadal bez znajomości oryginalnego hasła. Oczywiście, zawsze jest też opcja skorzystania z TeamViewera lub RustDeska i podejrzenia na żywo, co użytkownik może zobaczyć na ekranie, ale wówczas odbiorca musi być absolutnie pewien, że oddaje kontrolę właściwej osobie.

Czy istnieje alternatywa dla haseł?

Owszem, istnieją serwisy, w których hasła nie są potrzebne lub nie stanowią jedynej formy logowania. Przykładem są tzw. hasła jednorazowe lub tokeny, które są generowane na pewien krótki czas i przesyłane poprzez pocztę elektroniczną bądź SMS-em. Podobnie zresztą działa uwierzytelnianie dwuskładnikowe (2FA), które zawsze warto ustawiać w ważnych dla nas serwisach. Inną drogą jest biometria, czyli wykorzystanie odcisku palca, skanowania twarzy lub tęczówki. Jednak te rozwiązania, mimo że są już stosowane, budzą pewne wątpliwości pod kątem prywatności i dostępu do naszych danych osobowych lub wykorzystania wizerunku. Wreszcie, istnieje jeszcze opcja logowania się poprzez klucze SSH, jednak jest ona wykorzystywana raczej w specyficznych usługach i przez bardziej techniczne osoby.

Podsumowanie

Jak widać, wyciek hasła z bazy danych wcale nie musi oznaczać, że nasze dane uwierzytelniające są dostępne dla przestępców, co jednak też nie oznacza, że nie należy się mieć na baczności. Jeśli ktoś chce nam pomóc w problemie w serwisie, to praktycznie nigdy nie będzie potrzebował do tego hasła, a co najwyżej dobrej woli i współpracy z obu stron. Dlatego przyjmijmy zasadę, że nigdy nie ujawniamy naszych haseł, o ile nie jest to absolutnie koniecznie i nie dotyczy bliskiej nam osoby.

Jednocześnie nie należy się bać opcji przypomnienia hasła i tutaj mogę podać przykład z naszego podwórka - zmiana biblioteki do haszowania w Feedybacky, która wynikała z aktualizacji oprogramowania na serwerze, spowodowała, że użytkownicy musieli jeszcze raz ustawić swoje hasła. Nie mogliśmy tego zrobić automatycznie z uwagi na to, że... tych haseł nie znamy i nigdy nie poznamy. Także możecie się czuć spokojni.

Pozdrawiam i dziękuję - Jakub Rojek.