Od wielu lat serwisy typu Niebezpiecznik przekonują, iż hasła użytkowników rozmaitych aplikacji powinny być trzymane w postaci tzw. hashy, pozwalających na weryfikację hasła po jego wpisaniu, ale nie pozwalających na odtworzenie jego oryginalnej postaci.
Bardzo podobne środki sugeruje (choć nie wprost) obowiązujące od prawie 3 lat RODO. Chodzi o pewien aspekt bezpieczeństwa: jeżeli baza użytkowników „wypłynie” (albo stanie się coś takiego), to hasła użytkowników będą w miarę bezpieczne (jak bardzo, to zależy od konkretnych algorytmów użytych do przekształcenia hasła, a także od indywidualnej złożoności poszczególnych haseł).
Co to takiego ten „hash”? Jest to taka forma przedstawienia hasła, aby:
- mając oryginalne hasło, dało się zweryfikować jego znajomość
- nie mając oryginalnego hasła, nie dało się go odtworzyć
Hashe mogą mieć różną jakość, w zależności od użytej metody (lub wielu metod kaskadowo), użycia tzw. soli i innych technik utrudniających odtworzenie oryginalnego hasła.
Tak wygląda przykładowy hash: 998e141d9194fd1ec1dc3231eaeefafe.
Czasem zamiast algorytmów hashujących (np. SHA-256) używa się szyfrowania asymetrycznego (np. RSA), co pozwala uzyskać podobny efekt – z tą różnicą, iż takie hasła jest w stanie odszyfrować właściciel klucza deszyfrującego. Bezpieczeństwo haseł zależy wówczas od tego, kto ma dostęp do tego klucza i w jaki sposób jest on przechowywany i udostępniany.
Dlaczego więc tak wiele firm uparcie nie hashuje haseł?
Czy problemem jest zwyczajne oszczędzanie na programistach (ich czasie i umiejętnościach), czy może stoi za tym coś jeszcze?
Zacznijmy jednak od wyjaśnienia pewnej okoliczności:
Autor tego artykułu w ciągu ostatnich 20 lat pracował lub współpracował z przynajmniej kilkunastoma firmami, które trzymały hasła użytkowników w postaci jawnej. Niektóre z tych firm robiły to tylko ze względu na oszczędności, inne miały ku temu powody. Z tych drugich były to co najmniej:
- jedna z popularnych w Polsce platform aukcyjnych (ówcześnie działająca też w innych krajach)
- jedna ze znanych, dużych firm finansowych (takich bezpośrednio współpracujących z bankiem na równorzędnych zasadach, a nie np. jakieś biuro rachunkowe)
- jedna ze znanych firm ubezpieczeniowych
- jedna ze znanych firm hostingowych
- jeden ze znanych sklepów online (sklepów własnych, nie platform marketplace)
- jeden z serwisów pracy
- a wg wiedzy autora pozyskanej z pierwszej ręki, dokładnie to samo robi jeden z wiodących na świecie serwisów społecznościowych
Autor w prawie wszystkich wymienionych firmach podpisał umowę NDA, nie może więc ujawnić, jakie konkretnie techniki, narzędzia i sposoby działania stosuje konkretna firma. I nie jest to choćby istotne, bo to, która firma trzyma hasła w bazie danych Oracle, a która w Mongo, albo w jakim języku napisana jest aplikacja operująca na tych hasłach, nie ma dla czytelników żadnego znaczenia.
Zamiast tego opisany został pewien uśredniony stan rzeczy, bez wgłębiania się w szczegóły techniczne, a skupiając się jedynie na celu, jakim we wszystkich przypadkach jest identyfikacja sprawców nadużyć: wobec danej firmy, lub użytkowników wzajemnie wobec siebie.
Celem autora nie było ujawnianie unikalnych rozwiązań technicznych lub organizacyjnych stosowanych w którejkolwiek z firm, z którą ma podpisane NDA, a jedynie objaśnienie ogółowi społeczeństwa ogólnych mechanizmów, które wraz z biegiem lat i wraz z wymianą specjalistów IT między różnymi firmami, przestały być unikalne, a stały się relatywnie powtarzalne – i jako takie, nie podlegają już zapisom NDA.
No dobra, to teraz konkrety…
Przestępcy, próbując oszukać jakąś aplikację (tzn. jej operatora, bądź innych użytkowników), często stosują wiele różnych tożsamości i zarazem różnych kont w tej aplikacji. Mają wiele różnych sposobów działania, ale bardzo często powtarzającym się elementem jest właśnie stosowanie wielu tożsamości.
Posługiwanie się wieloma tożsamościami ma trzy podstawowe wady:
- ciężko te wszystkie dane zapamiętać
- ich przekazywanie między różnymi osobami staje się kłopotliwe
- łatwo się odruchowo pomylić (ale to temat na inny artykuł)
Aby choćby częściowo rozwiązać pierwsze 2 problemy, wielu przestępców stosuje schematy, zwłaszcza tam, gdzie wydaje im się, iż tego nie widać – czyli np. w konstruowaniu haseł.
Schematy haseł? A co to takiego?
Wyobraź sobie, iż masz do zapamiętania 20 różnych haseł do 20 różnych kont (a jeżeli masz wyjątkowo dobrą pamięć i 20 haseł nie jest dla Ciebie problemem – wyobraź sobie 200 kont).
Jeśli jesteś mało roztropny, ustawisz na wszystkich kontach hasła typu „123456” albo „login12” – takich użytkowników cały czas jest choćby kilkanaście procent.
Przestępcy są jednak nieco bardziej roztropni – zdają sobie w końcu sprawę, iż ktoś może ich ścigać, a w międzyczasie próbować przejmować ich konta (z których przecież żyją). Zwykle ustawiają więc trudniejsze hasła. Tu jednak wracamy do wspomnianych wyżej problemów: ciężko zapamiętać, ciężko przekazać komuś innemu. Rozwiązaniem są właśnie schematy haseł w stylu:
- login_Bolec, login_Kolec, login_Stolec
- Darth_login_Vader, Han_login_Solo
- D@rthV@der, HanS0l0
- pOziomki27, tRuskawki33, mAlinki19
- Puch@tek84, Prosiacz3k1984, 19Kl@pouchy84
Kreatywność użytkowników (nie tylko przestępców!) jest na tym polu zdumiewająca. Jest już chyba dość oczywiste, iż mając do dyspozycji tylko hashe, nie jesteśmy w stanie szukać żadnych zależności pomiędzy takimi hasłami. Jedyne, na co pozwalają hashe, to sprawdzenie, czy 2 hasła są identyczne – a to dla niektórych firm za mało…
No to co z tymi hasłami robią duże firmy?
Przede wszystkim, trzymają hasła w postaci jawnej. Przy czym niekoniecznie w tej samej bazie danych, co resztę danych – np. w głównej bazie danych mogą być trzymane tylko hashe, a hasła, loginy, numery użytkowników, nazwiska, imiona i inne parametry typowo używane w schematach mogą być kopiowane do odrębnej bazy analitycznej, do której ma dostęp tylko kilku najbardziej zaufanych pracowników.
Niemniej jednak, hasła są gdzieś trzymane w postaci jawnej. A choćby więcej: często są tak trzymane nie tylko bieżące hasła, ale też ich cała historia.
Następnie, hasła te poddawane są tzw. normalizacji – a więc w najprostszej wersji:
- polskie litery zamieniane są na zwykłe (np. „ą” na „a”)
- duże litery zamieniane są na małe
- cofane są typowe przekształcenia, np. „@” zamieniane jest na „a”, „3” na „e” itd.
- wychwytywane są zawarte w haśle loginy, numery użytkowników, nazwiska itp. i podmieniane na stałe tokeny typu „login”
- pozostałe cyfry i znaki specjalne są usuwane
I tak np. z wymyślnego hasła „D@rthV@der” robiony jest zwykły „darthvader”. To jednak tylko najprostsze z przekształceń – tak naprawdę w niektórych firmach robi się ich choćby setki, wg różnych wzorców – wzorców pisanych przez analityków, którzy wcześniej oglądają zestawienia realnych haseł i pozostałych danych realnych użytkowników.
Nawiasem mówiąc… czy RODO pozwala firmom cywilnym na takie grupowe działania na danych osobowych? Nie jest to przypadkiem domeną tzw. podmiotów uprawnionych?
W kolejnym kroku różne hasła są ze sobą porównywane. I nie tylko bezpośrednio ze sobą, ale również z rozmaitymi słownikami, np.:
- nazw postaci z Gwiezdnych Wojen i wielu innych cykli filmowych
- nazw miast, ulic, imion, popularnych nazwisk
- popularnych słów kluczowych z cytatów z filmów, seriali, bajek dla dzieci, reklam (np. przez kilka lat bardzo popularne były cytaty z reklam operatorów GSM, np. Turbodymoman, a wcześniej różne słowa z reklam z udziałem Kabaretu Mumio)
- nazw kanapek fastfoodowych
Poza porównywaniem wprost często robiony jest też tzw. stemming, czyli usunięcie ze zidentyfikowanego słowa końcówki fleksyjnej (np. „instrukcja” -> „instrukcj”), dzięki czemu można próbować kolejno dopasowywać różne końcówki: liczby pojedyncze i mnogie, odmianę przez przypadki itd.
Kolejną stosowaną techniką jest mierzenie tzw. odległości Levenshteina – a więc jeżeli choćby nie uda się odwrócić wszystkich przekształceń zastosowanych przez użytkownika i hasło nie będzie w 100% identyczne z żadnym wariantem, przez cały czas może zostać wychwycone jako „wystarczająco podobne” i zakwalifikowane do dalszej analizy manualnej przez analityka, który następnie może dopisać do aplikacji kolejne reguły przekształceń.
Ok, mamy grupę podobnych haseł. Co dalej?
Wyniki pracy narzędzia porównującego hasła są najczęściej (niestety nie wszędzie) kierowane najpierw do weryfikacji manualnej – tak aby odsiać ewentualne fałszywe trafienia (najczęściej w wyniku zbieżności danych osobowych kilku całkiem różnych osób, np. dwóch różnych Janów Kowalskich z Warszawy ma kolizję drogową, albo jeden od drugiego coś kupił na aukcji).
Zaś po przejściu weryfikacji manualnej, wyniki przekazywane są do głównej aplikacji i łączone z wynikami pozyskanymi z innych systemów antyfraudowych (np. sprawdzających adresy IP logowań, czy fingerprintujących przeglądarkę użytkownika), w wyniku czego finalnie na kontach użytkowników zaznaczane są prawdopodobne podejrzane powiązania z innymi kontami:
- prawdopodobne „spółdzielnie” – czyli grupy różnych osób, prawdopodobnie działających w zmowie
- prawdopodobne „multikonta” – czyli prawdopodobnie pojedyncze osoby używające wielu tożsamości
- inne użyteczne informacje, jakie udało się wychwycić (zależne od konkretnej firmy i jej systemów)
Przy czym nie wszystkie firmy potrafią odróżniać „spółdzielnie” od „multikont” – nie dla wszystkich firm ma to zresztą znaczenie (zależy to od specyfiki konkretnego biznesu).
A to, co się z takimi kontami dzieje dalej, to już zależy od konkretnej firmy. Generalnie jednak takim kontom zaczynają dokładnie przyglądać się pracownicy odpowiedzialni za rozmaite aspekty bezpieczeństwa i często kończy się to przygotowywaniem rozmaitych zestawień i/lub innych dokumentów dla policji i prokuratury…
Co robić, jak żyć (na wolności)?
Przede wszystkim pamiętać, iż nic, co wydaje się „tajne” dla zwykłych użytkowników, nie musi być tajne dla operatora tej lub innej aplikacji. A kiedy już to zapamiętamy – unikać schematów również w doborze haseł.
Można też, jak zauważyło kilku czytelników, stosować menedżery haseł (które pozwalają przy okazji generować w pełni losowe hasła), a w razie potrzeby wymieniać się ich profilami, zamiast pojedynczymi hasłami.
Intencją autorów ani wydawcy treści prezentowanych w magazynie PAYLOAD nie jest namawianie bądź zachęcanie do łamania prawa. jeżeli popełniłeś lub masz zamiar popełnić przestępstwo, bądź masz wątpliwości, czy Twoje działania nie będą łamać prawa, powinieneś skonsultować się z najbliższą jednostką Policji lub Prokuratury, a jeżeli są one związane z pieniędzmi, dla pewności również z Urzędem Skarbowym.
Nie zezwala się na użycie treści prezentowanych w magazynie PAYLOAD, ani produktów dostępnych w sklepie PAYLOAD, do celów popełniania przestępstw lub przestępstw skarbowych.