Hej, hej... Programisto, to kolejny artykuł dla Ciebie! Druga część artykułu na temat wzorców projektowych. Poznaj Adapter oraz Memento.
Dzisiaj chcemy Wam opowiedzieć więcej o hasłach, a przede wszystkim jakie ataki dotyczące haseł czyhają na użytkowników Internetu i programistów. Pojawią się także pojęcia związane z hashami, także jeśli nie czytałeś poprzedniego artykułu dotyczącego funkcji haszujących na naszym blogu, to zachęcamy. A teraz, zapraszamy do lektury!
Hasło, czyli udowodnij, że Ty to Ty
Jakiś czas temu w artykule na blogu omawialiśmy metody uwierzytelnienia i problemy dotyczące tożsamości użytkownika. Hasła są jedną z podstawowych metod uwierzytelnienia, czyli udowodnienia przez użytkownika, że jest tym za kogo się podaje. Całość opiera się więc na założeniach, że tylko określony użytkownik zna hasło (jest utrzymywane w tajemnicy) oraz że hasło nie jest łatwe do odgadnięcia. Dawno temu, kiedy nie istniały dobre praktyki do tworzenia haseł, ludzie tworzyli je w oparciu o pojedyncze słowa, imiona czy daty urodzin bliskich albo proste numery. Dziś wiemy, że takie podejście przy wzroście zaawansowania technik łamania haseł oraz mocy zwiększenia dostępnej mocy obliczeniowej jest niewystarczające.
Jak przechowywane są hasła?
Odpowiedź brzmi – to zależy. Mówi się często o tym, że hasła nie powinny być szyfrowane i że należy je hashować. Są jednak sytuacje, gdzie aplikacje faktycznie szyfrują hasła np. w menadżerach haseł, gdzie muszą być one przechowywane jako tekst a nie jako hash. Dokumentacja menadżera 1password podaje na przykład, że ich aplikacja używa AES-GCM-256 do szyfrowania hasła. W większości przypadków jednak aplikacje internetowe powinny przechowywać hasła w postaci hashy, a nie je szyfrować.
Hashe a aplikacje internetowe
Jeśli użytkownik tworzy konto w naszej aplikacji, aplikacja powinna założyć konto poprzez utworzenie odpowiedniego wpisu w bazie danych. Hasło, które wybrał użytkownik, powinno być podane do funkcji skrótu – a wyjściowy łańcuch o stałej długości powinien być zapisany razem z wpisem konta w bazie. Można tutaj dodać inne mechanizmy do naszej aplikacji takie jak tzw. sól i pieprz, ale na razie skupmy się na podstawach.
Jeśli użytkownik ma już utworzone konto i próbuje się zalogować do aplikacji, to bierze ona podane przez niego hasło, ponownie hashuje i sprawdza wpis w bazie. Jeśli wszystko się zgadza, to dopuszcza użytkownika do jego konta (np. poprzez SessionId czy Token).
Rysunek 1 – proces tworzenia i werfikacji hasła, źródło: lucidoutsourcing
Hashowanie jest jak pamiętamy jednostronną funkcją matematyczną, to znaczy, że z uzyskanego w ten sposób skrótu nie da się odzyskać hasła. Oznacza to, że nawet jeśli baza danych wycieknie to haker nie będzie w stanie odzyskać przechowywanych tam haseł – oczywiście pod warunkiem, że wykorzystamy bezpieczne praktyki i prawidłowo zaimplementujemy mechanizmy.
Metody ataków
Aby zrozumieć dokładnie z czego wynikają dobre praktyki, należałoby poznać metody ataków stosowane przez hakerów w celu przełamania bezpieczeństwa hasła. Są to między innymi:
– brute force – atak siłowy, czyli taki, który polega na sprawdzeniu wszystkich dostępnych kombinacji czy to znakowych czy liczbowych. Jesli haker wie, że dane hasło ma 8 liter i jest skonstruowane z małych liter, to ma do wypróbowania 26^8 kombinacji. Wszystkie kombinacje możemy sprawdzić w kilka godzin z pomocą zwykłego komputera. Scenariuszem ataku może tu być: łamanie pozyskanego hasha (poprzez wygenerowanie wszystkich kombinacji 8-literowych i następnie porównanie z naszym hashem offline) lub próba odgadnięcia hasła do aplikacji internetowej (takiej, która mimo setek requestów nie zbanuje naszego adresu ip/konta na które chcemy się zalogować – atak online) bądź próba włamania do wi-fi. Przy dodatkowych mechanizmach bezpieczeństwa ograniczających ilość prób bądź przy odpowiednio długich hasłach o wysokiej entropii taki atak nie jest możliwy do przeprowadzenia w skończonym czasie
– tablice tęczowe (ang. rainbow tables) – ataki wykorzystujące tablice tęczowe polegają na przeszukiwaniu gotowych tablic zawierających mapowania hasha do hasła, aby nie musieć samemu poświęcać czasu na generowanie, a jedynie na przeszukiwanie haseł. Musimy jednak wiedzieć jaki algorytm haszujący został zastosowany, ponieważ dla każdego hasła inny algorytm zwróci inny hash. Tablice można zobaczyć choćby na stronie https://freerainbowtables.com/ . Jest to po prostu optymalizacja ataku bruteforce. Dodawanie soli do haseł zapisywanych w bazie, czyli pewnego ciągu znakowego indywidualnego dla każdego z użytkowników sprawia (zapisywanego również w bazie) sprawia, że gotowe tablice tęczowe nie mają zastosowania nawet dla popularnych haseł i dodatkowo użytkownicy posiadający te same hasła mają różny hash.
Rysunek 2 – tablice tęczowe dla różnych polityk haseł dla różnych algorytmów haszujących. Widać, że te bazy ważą często setki gigabajtów, a nie ma tu np. kombinacji ze znakami specjalnymi (jedynie alphanumeric/lower alpha czy numeric).
– atak słownikowy – aby ograniczyć liczbę dostępnych kombinacji, można wykorzystać ten rodzaj ataku. Polega on na użyciu lub wygenerowaniu własnego słownika najczęściej używanych zwrotów w hasłach i tworzeniu ograniczonej liczby kombinacji. Agregując hasła, które dostępne są po wyciekach danych z różnych firm, hakerzy tworzą ogólnodostępne słowniki, sortowane według najczęściej używanych haseł jak np. bardzo znana wordlista rockyou. Hakerzy kradnąc źle zabezpieczoną bazę danych (hasła przechowywane w plaintext, hashowanych za pomocą niebezpiecznych funkcji skrótu lub hashowane bez soli) agregują to w listy i następnie używają najczęściej używanych haseł w atakach. Dodatkowo można korzystać z takich narzędzi jak choćby hashcat, dzięki któremu jesteśmy w stanie na podstawie podanego hasła np. “password” wygenerować jego pochodne jak “password1”, “p@ssword” czy “p@sword123”. Dostępne są także badania naukowe, które wskazują na to, że ludzie naturalnie umieszczają liczby i znaki specjalne na końcu hasła.
– atak typu spray – ten atak polega na wzięciu przez hakera kilku najczęściej używanych haseł i próbie przełamania zabezpieczeń poprzez zmianę loginu, na który chce się zalogować. Załóżmy, że haker wejdzie w posiadanie bazy danych aplikacji z naszej firmy, gdzie hasła zostały poprawnie zahashowane. Nie opłaca mu się robić ataku siłowego, ale mając dostępne loginy kont i znając najczęściej wykorzystywane hasła w Internecie może spróbować logować się na każde z kont z użyciem kilku tych samych haseł. Co ważne, systemy związane z wykrywaniem wielokrotnych prób logowania w aplikacji mogą być nieskuteczne, ponieważ atakujący za każdym razem próbuje zalogować się na inne konto. Atak offline typu spray jest także możliwy, jeśli chcemy łamać hashe, których nie ma w tablicach tęczowych.
– atak pass-the-hash – jeśli dana aplikacja/system oczekuje jako inputu do zweryfikowania użytkownika hasha zamiast hasła, to wyciek hasha sprawia, że nie trzeba poznawać hasła. Jeśli osoba atakująca uzyska dostęp do tych hashowanych haseł (na przykład poprzez włamanie się do systemu i inspekcje pamięci operacyjnej lub podręcznej), może użyć tych zaszyfrowanych haseł bezpośrednio do uwierzytelnienia w sieci, bez potrzeby używania haseł w postaci zwykłego tekstu. Dlatego też dobrą praktyką jest hashowanie dopiero po stronie aplikacji backendowej
– keylogger – jeśli na nasz komputer dostanie się malware np. poprzez e-mail phishingowy, to wirus dokonując inspekcji naszego komputera i tego, co wpisujemy może dowiedzieć się, jakie mamy hasło
– sniffing – jeśli atakujący dostanie się do sieci może próbować przeprowadzać ataki MITM, które pozwalają na inspekcje naszego ruchu. Większość dzisiejszej komunikacji jest szyfrowana, ale stosując dodatkowe techniki (TLS downgrade, SSL stripping) i przy odpowiednich założeniach atakujący może wykraść nam hasła.
– reverse engineering – atakujący mogą próbować analizować kod aplikacji poprzez narzędzia do inżynierii wstecznej, aby odkryć zaszyte tam domyślne, systemowe hasła. Jest to popularne w rozwiązaniach IOT. Samo zaszywanie przez producenta pewnych awaryjnych systemowych haseł jest karygodnym błędem i może wynikać z niedopatrzenia na którymś z etapów produkcji oprogramowania.
– shoulder surfing lub kamery – atakujący może po prostu patrzeć nam przez ramię gdy wpisujemy nasze hasło lub to co wpisujemy może być nagrane na kamerę
– atak key-wrench – jest to rodzaj ataku fizycznego, gdzie ktoś nie zważając na mechanizmy kryptograficzne szantażuje lub torturuje swoją ofiarę dopóki nie poda mu swojego hasła
– inne ataki – lista zagrożeń oczywiście nie jest kompletna i nie da się takiej listy stworzyć. Inne ataki mogą wykorzystywać bardziej zaawansowane techniki zależne od stosowanych przez ofiarę technologii
Rysunek 3 – komiks pokazujący jak pomimo zaawansowanych zabezpieczeń technologicznych uwzględnienie zagrożenia fizycznego może być tragiczny w skutkach dla bezpieczeństwa, źródło: XKCD’s Wrench Attack Cartoon
Podsumowanie
Istnieje więc wiele typów ataków, które są bardziej lub mniej techniczne. Jeśli chcesz, aby Twoja firma była bezpieczna, najlepiej powierzyć zadanie zabezpieczenia w ręce ekspertów. Temat jest bardzo szeroki, ale to co możesz zrobić to przeczytać nasze artykuły odnośnie dobrych praktyk cyberbezpieczeństwa, aby znacząco obniżyć szanse na bycie ofiarą ataku.
Za tydzień opowiemy Wam jakie są dobre praktyki dotyczące haseł – zarządzania nimi i ich przechowywania. Zapraszamy!
