Hubert Taler / 13.12.2017

Sól, hashe i inne przyprawy: fascynująca historia haseł w informatyce

21 interakcji Przejdź do dyskusji

Właściciele nowszych telefonów jedynie na nie spoglądają i to wystarczy do identyfikacji użytkownika. W starszych telefonach też dawno zrezygnowano z wpisywania PIN-u – należy tylko dotknąć przycisku, a urządzenie rozpozna nasze linie papilarne. Biorąc pod uwagę, że komputery zaczynają również wspierać tego typu logowanie – np. Windows Hello pozwala nam zalogować się za pomocą twarzy, możemy odnieść mylne wrażenie, że biometria jest przyszłością uwierzytelniania użytkownika.

Jak jest w rzeczywistości? Kiedy pojawiły się hasła do komputerów? Jak ewoluowały? Czy rzeczywiście metody biometryczne zastąpią je, czy jedynie wzbogacą arsenał środków bezpieczeństwa?

Po co powstały hasła?

W 1959 roku Christopher Strahey opublikował prelekcję Time Sharing in Large Fast Computers (Dzielenie się czasem użytkowania dużych i szybkich komputerów). Ogłosił ją w trakcie konferencji UNESCO w Paryżu poświęconej przetwarzaniu danych. Pokazał w niej niesamowitą wizję: programista poprawia program na konsoli komputera (wciąż wyglądającej jak teleks), podczas gdy inny program był uruchomiony na tym samym komputerze. Wizja była wspaniała: dotychczas programiści nie mogli poprawiać programu działającego na komputerze – musieli po wystąpieniu błędu ponownie go napisać i przekazać do uruchomienia. Było to tzw. przetwarzanie wsadowe.

Prezentację Straheya widział pracujący na MIT amerykański prekursor informatyki John McCarthy. Udało mu się doprowadzić na swojej uczelni do tego, że stworzono specjalny zespół, mający na celu implementację wizji Straheya, czyli podział czasu komputera pomiędzy użytkowników – tzw. time sharing.

W lipcu 1961 na zasadzie time-sharingu działalo już kilka poleceń na maszynie Computation Center IBM 709. Tak powstał CTSS – Compatible Time Sharing System. Powstało pytanie – jak rozpoznać konkretnego użytkownika, który mógł podejść do każdej z dostępnych końcówek systemu? Powstała potrzeba metody na to, aby drogi dostęp do czasu pracy komputera móc jakoś kontrolować.

Powstaje polecenie login… i następuje pierwsze włamanie

Tak powstało polecenie login. Dziś wbudowane w graficzny interfejs użytkownika, w czasach CTSS po prostu oczekiwało dwóch argumentów. Pierwszym była nazwa użytkownika, drugim było hasło – podawane w postaci niezaszyfrowanej. Ponieważ w tamtych czasach typowym terminalem do komputera był teletype – czyli coś w rodzaju teleksu, urządzenie z drukarką i klawiaturą, to twórcy programu login starali się powstrzymać drukowanie hasła w trakcie jego wpisywania. Działało to podobnie jak dziś, gdy logujemy się w konsoli i na ekranie nie widać hasła, które podajemy.

Hasła w ówczesnych systemach trzymane były w formie pliku tekstowego w postaci niezaszyfrowanej. Przetrwało to aż do pierwszych wersji systemów Uniksowych, gdzie w pliku /etc/passwd hasła początkowo były przedstawione bezpośrednio.

W 1962 roku dr Allan Scherr, któremu za mało było przydzielonego mu czasu pracy na komputerze, wpadł na pomysł wykorzystania czasu innych kolegów z uczelni. W tym celu wydrukował sobie plik z hasłami, część wykorzystując samemu, a resztę rozdając. W ten sposób powstał pierwszy prawdziwy wyciek haseł i pierwsze związane z tym naruszenie bezpieczeństwa. Powstało pytanie: jak zabezpieczyć hasła przed niepowołanymi oczami, równocześnie zachowując możliwość sprawdzenia ich z poziomu programów systemowych.

Zabezpieczanie haseł użytkowników

Już w systemie Multics, w połowie lat 1960., wprowadzono tzw. funkcję skrótu w celu ochrony haseł. Na czym to polegało? W odróżnieniu od typowych zastosowań szyfrowania, funkcja skrótu zwraca unikalną wartość dla zaszyfrowanej treści lecz nie pozwala na odzyskanie oryginalnego tekstu. Eliminuje to konieczność przechowywania haseł w ogóle – przecież wystarczy użyć tej samej funkcji skrótu na wartości wpisanej przy logowaniu i porównać z zapisanym skrótem tzw. hashem.

Taką funkcjęwprowadził w 1965 roku w systemie Multics Tom Van Vleck. Wymyślił on bardzo prostą funkcję skrótu: wartość binarną hasła potraktował pierwiastkiem kwadratowym i dodatkowo przełączył kilka bitów unikalną maską bitową za pomocą mnożenia bitowego (AND). To właśnie wynik tego działania był przechowywany w /etc/passwd i był porównywany z hashem wpisanego hasła. Całe porównanie mogło się odbyć bez znajomości oryginalnego, niezahashowanego hasła.

Niestety, pierwszy w historii hash został złamany w trakcie audytu bezpieczeństwa dokonanego w 1972 roku przez amerykańską armię, a konkretnie zespół wydelogowany przez Air Force. Okazało się że bez trudu wymyślili oni hasło, które generowało ten sam skrót (dziś nazywamy to kolizją hashy). Zmusiło to Van Vlecka do stworzenia lepszej funkcji skrótu. Nadal każdy wciąż widział hash przechowywany w pliku z hasłami.

Kolejne zmiany w funkcjach skrótu były zarówno jakościowe jak i ilościowe. Budowano coraz bardzie złożone algorytmy skrótu, mające zapewnić minimalizację prawdopodobieństwa kolizji.

Usprawnianie funkcji skrótu

Funkcje skrótu pozostały z nami do dziś, były jednak wciąż usprawniane. Problemem we wczesnych latach Uniksa był fakt, ze bardzo szybko można było przetestować wiele tysięcy haseł by porównać hash. Liczenie funkcji skrótu nie było więc wystarczająco kosztowne obliczeniowo, i dawało przewidywalne rezultaty.

W wersji 7 Uniksa (1979) wbudowano funkcję crypt która została zbudowana przy pomocy algorytmu DES (ang. Data Encryption Standard). DES miał dwie zalety: trudno go było “odwrócić”, oraz… był powolny w implementacji software’owej. Wbrew pozorom była to zaleta, bo utrudniała łamanie haseł metodą brute force. Miał jeszcze jedną, istotną cechę: można go było sparametryzować, przez co lokalne instalacje Uniksa mogły mieć różne wyniki przy szyfrowaniu tego samego hasła.

Kolejne usprawnienie jakie wprowadzono jeszcze w latach 70. było “solenie” haseł przed ich zahashowaniem. Solenie (ang. salting) polegało na dodaniu do hasła losowej liczby, która miała na celu zwiększenie unikalności hasha oraz do uniknięcia sytuacji w której jesteśmy w stanie rozpoznać, że ktoś używa tego samego hasła na różnych systemach. Dzięki przyprawieniu hasła za pomocą soli obliczone hashe miały różna wartość.

Wkrótce, po wprowadzeniu tzw. shadowingu, hasła i ich skróty w ogóle zniknęły w ogólnie dostępnych plikach systemowych.

Lepsza jakość haseł – lepsze bezpieczeństwo

Szybko zorientowano się, że lepsza jakość haseł przekłada się na lepsze bezpieczeństwo systemu. Użytkownicy, którzy mają hasła unikalne, nie oparte na słowach ze słownika i odpowiednio długie, mogą liczyć na lepszą ochronę swoich danych. W jaki sposób jednak sprawdzać jakość haseł, skoro w systemie przechowujemy jedynie wynik funkcji skrótu?

Próbowano zrobić to na dwa sposoby, a próby te pojawiły się na przełomie lat 70. i 80. Pierwszym sposobem była modyfikacja programu który pozwalał zmienić użytkownikowi hasło (passwd). Pojawiły się wersje tego programu, które sprawdzały lokalnie jakość hasła (według zakodowanych reguł) i zachęcały użytkownika do ustawienia hasła lepszego. Ta funkcja przeżyła w systemach uniksowych do dziś – np. w Linuksie sprawdzanie złożoności hasła jest realizowane przez moduł jądra.

Drugim sposobem, w jaki walczono z niską złożonością haseł ustawianych przez użytkowników było… zwiększenie ich złożoności w ukryty sposób. W warstwie logowania dodawano przypadkowe liczby do hasła, a użytkownik w rzeczywistości logował się do systemu hasłem o wiele bardziej złożonym niż wpisał. Później ta metoda wyewoluowała w cały zestaw metod związanych z tzw. password stretchingiem.

Wyścig zbrojeń

Lata 90. były rajem dla każdego, kto interesował się cudzymi sekretami. Hasła w sieci były zazwyczaj przesyłane w formie otwartego tekstu, a dane były wysyłane przez sieć kablową, do której bardzo łatwo było się dostać. Typowy atak polegał na nasłuchiwaniu (sniffing) haseł, korzystając z maszyny znajdującej się w tym samym segmencie sieci lokalnej. Dekada ta przyniosła dużo narzędzi zarówno przeznaczonych dla crackerów (łamiących hasło) jak i dla specjalistów bezpieczeństwa.

Gdy się skończyła – rozpoczął się wyścig zbrojeń, który trwa do dziś – coraz bardziej złożone obliczeniowo algorytmy są atakowane na nowe sposoby.

Nowe metody ataków, które nie mogły istnieć wcześniej to np. ataki za pomocą mocy obliczeniowej GPU (procesorów graficznych). Za pierwszy zademonstrowany publicznie taki atak uważa się eksperyment Andreya Belenko z Elcomsoftu z 2007 roku. Udało mu się uzyskać wtedy prędkość 100 milionów sprawdzeń na sekundę. Wkrótce, również dzięki postępowi w rozwoju sprzętu graficznego, wydajność na sekundę była liczona już w miliardach!

Pojawia się uwierzytelnianie wielopoziomowe

Zmianą jakościową w ochronie danych przy pomocy haseł było pojawienie się uwierzytalniania wielopoziomowego. Jego wprowadzenie wynikało ze zmiany myślenia: skoro zwiększanie trudności algorytmów powoduje zwiększanie mocy obliczeniowej po stronie łamiącego, trzeba uciec w bok i wymyślić coś, na co nie pomoże zwiększona moc obliczeniowa.

Tym pomysłem było zwiększenie informacji, które musi dostarczyć użytkownik. Część z nich była trudniej dostępna lub zużywała się. Używa się w tym celu tokenów, które wyświetlają zmieniające się cyfry lub karty kodowe, które zawierają listę kodów jednorazowego użytku.

Uwierzytelnianie dwupoziomowe (2 factor authentication lub w skrócie 2FA) najwcześniej zostało szeroko wprowadzone w ofercie banków. Stało się to na przełomie wieków. I chociaż od razu poddano je krytyce, zdobyło sobie sporą popularność, bo faktycznie zwiększało bezpieczeństwo.

Amerykański kryptograf i specjalista z zakresu cyberbezpieczeństwa Bruce Schneier, już w 2005 roku w następujący sposób wypowiedział się na temat 2FA:

Uwierzytelnianie dwuskładnikowe nas nie zbawi. Nie ochroni nas przed phisingiem (wyłudzaniem danych – SW). Nie zapobiegnie kradzieży tożsamości. Nie zabezpieczy kont w bankach online przed oszukańczymi transakcjami. Rozwiązuje problemy z bezpieczeństwem, jakie mieliśmy 10 lat temu, a nie te, które mamy teraz.

Dość surowa recenzja, prawda? Mimo to uwierzytelnianie wieloskładnikowe jest dziś podstawą dostępu do wielu usług online oraz do poszczególnych urządzeń. Wiele usług sieciowych takich jak GMail czy Dropbox pozwalają dziś włączyć logowanie z dwoma składnikami: hasło oraz kod przysyłany SMS-em lub do aplikacji na telefonie.

Aby zwiększyć skuteczność uwierzytelniania wieloskładnikowego, stosuje się zasadę podziału domen dla poszczególnych składników. Najczęściej stosuje się następujący podział na:

  • Coś, co wiesz:
    • hasło
    • PIN
    • rozpoznanie obiektu na fotografii
  • Coś, co masz:
    • Token wyświetlający kod
    • Karta chipowa
    • Telefon z aplikacją lub obierający SMS
  • Coś, czym jesteś:
    • Siatkówka oka
    • Linie papilarne
    • Twarz
  • Coś, co robisz:
    • Zachowanie, sposób pisania
    • Lokalizacja
    • Reputacja

Dopiero przy zastosowaniu dwóch lub więcej z elementów wymienionych powyżej, możemy mówić o skutecznym zastosowaniu wieloskładnikowego uwierzytelniania. Czy jest to ideał? Na pewno nie, ale jest i tak wielokrotnie skuteczniejszy niż uwierzytelnianie używające jednego składnika.

Jakie mogą wiązać się z tym zagrożenia?

Przede wszystkim zwiększona liczba tzw. fałszywych negatywów (false negatives) – sytuacji, w których jesteśmy osobą uprawnioną, ale nie jesteśmy w stanie poradzić sobie z jednym z kroków uwierzytelniania. Każdy, kto nie potrafił wpisać poprawnie tekstu do CAPTCHA, wie dobrze o czym mówię. Przykłady można by mnożyć:

  1. Linie papilarne mogą być nierozpoznane, gdy zranimy się w palec, mamy na nim plaster albo palec jest po prostu spocony.
  2. Często nie jesteśmy w stanie powtórzyć tego samego sposobu pisania lub wykonać idealnego podpisu zgodnego ze wzorcem.
  3. Możemy być w nietypowej lokalizacji, a mimo to działać zgodnie z zamierzeniami – dziś zdarza się, że bank blokuje kartę komuś, kto użył jej w nowym dla niego kraju.

Niestety, atakujący też o tym wiedzą i wykorzystują socjotechnikę w celu obejścia jednego lub więcej składnika w uwierzytelnianiu. Przecież można zadzwonić do obsługi i powiedzieć, że dziś nie może się spojrzeć w czytnik siatkówki oka, bo mamy zapalenie spojówek prawda?

Jaki z tego wniosek? Wyścig zbrojeń trwa – i zapewne w kolejnych latach zobaczymy jeszcze lepsze metody zabezpieczania naszych informacji i jeszcze lepsze metody ich łamania.

Advertisement