Połam to lepiej

Niedawno brałem udział w konkursie organizowanym przez Sekurak.pl. Konkurs polegał – jak to się potocznie mówi – na „łamaniu haseł”. Poprawniej byłoby rzec, że polegał na odzyskiwaniu haseł na postawie hashy, ale mniejsza o to. Udało mi się wygrać, tzn. złamałem największą ilość haseł jako pierwszy. Teoretycznie więc mógłbym na tym poprzestać, ale – z perspektywy patrząc – pewne rzeczy można było zrobić albo opisać lepiej. Oryginalny writeup mój i innych zwycięzców można znaleźć w tym artykule, natomiast ten wpis jest jedynie jego uzupełnieniem.

Dla przypomnienia, jeśli chodzi o gotowce, skorzystałem ze reguł wbudowanych w hashcata, reguły OneRuleToRuleThemAll[1]. Zaś jeśli chodzi o gotowe słowniki to użyłem RockYou, Ignis (10 mln) oraz słownika języka polskiego dostępnego w Debianie w pakiecie wpolish.

Co można zrobić lepiej? Przede wszystkim ten wpis na blogu daje namiar na „growy” słownik języka polskiego. Jest on mniejszy od tego z wpolish. Zawiera 3,2 mln linii, zamiast 4,3 mln. Mogłoby wydawać się to wadą, ale… przy skomplikowanych operacjach większy słownik nie musi być lepszy.

Słownik growy zawiera znaki końca linii w formacie windowsowym. Można je przekształcić na format uniksowy np. w taki sposób:

cat slowa.txt | perl -ne 'chomp; /(\S+)/ && print $1,$/' > slowa_unix.txt

Taka wersja przyda się w kolejnych operacjach.

Słownik wpolish można z kolei znormalizować przez usunięcie wielkich liter. Nie mają one znaczenia, bo występują na początku i któraś reguła hashcata z pewnością uwzględnia takie przekształcenie. Polecenie

cat /usr/share/dict/polish | tr "[:upper:]" "[:lower:]" | sort -u > wpolish_lower.txt

redukuje wielkość słownika o 46k wierszy, czyli nieco ponad 1%.

Z kolei jeśli chodzi o najbardziej kompletny słownik języka polskiego, to będzie nim złączenie znormalizowanego wpolish oraz growego z poprawionymi końcami nowej linii:

cat slowa_unix.txt wpolish_lower.txt | sort -u > slownik_all.txt

Wynik jest o jedynie 5k linii większy od oryginalnego wpolish.

Pozbycie się pl-znaków ze słownika:

cat slownik_all.txt | tr "ąćźżńłóęś" "aczznloes" | sort -u > slownik_all_nopl.txt

Łatwo zauważyć, że jeśli ktoś będzie miał hasło, które jest wyrazem w języku polskim, ale zapisanym w sposób mieszany, częściowo z polskimi znakami, częściowo wersją polskawą, to nasze słowniki taki wyraz ominą. Przykładem takiego słowa może być wyraz żółty zapisany jako zólty. Co wtedy?

Pomóc może zrobienie własnej reguły hashcata, wykorzystującą zastąpienie, czyli s:

Replace sXY Replace all instances of X with Y

Można od razu w podobny sposób potraktować „jednoliterowe” błędy ortograficzne i regułą zastąpić u przez ó i na odwrót. Niestety, z tego co widzę przy pomocy samego hashcata nie da się zrobić ani przekształcenia ch -> h, ani odwrotnego. W dodatku powyższe zastąpienie dotyczy wszystkich wystąpień, a niezupełnie o to chodzi. Jednak lepszy rydz, niż nic.

Tyle gwoli uzupełnienia. Regułę hashcata pozostawiam do samodzielnego montażu, a o zewnętrznym skrypcie do przekształceń jeszcze pomyślę.

[1] Celowo linkuję do genezy powstania, której lekturę gorąco polecam, nie samej reguły.

FireHOL – brak aktualizacji

Przy okazji wpisu o antyspamie na WordPress pisałem o wykorzystaniu list z doskonałego projektu FireHOL do blokowania ruchu. Działało świetnie, działać przestało. Przynajmniej częściowo. W repozytorium na Githubie widać bowiem, że ostatnia aktualizacja jest sprzed dwóch miesięcy.

Sprawdzając dokładniej trafimy na issue Github lists no longer being updated. Listy budowane są przy pomocy crona. 23 marca miała miejsce zmiana klucza SSH używanego przez Github. Tego samego dnia przestało się aktualizować repo FireHol. Przypadek?

I tak sobie radośnie aktualizacje leżą od blisko dwóch miesięcy. To może nie być po prostu dłuższy urlop…

W każdym razie, jeśli ktoś korzysta z powyższych list i zależy mu na aktualizacjach, to polecam przepiąć się na wersję bezpośrednio ze strony projektu. Dostępnej pod linkiem download local copy dla każdej z list. Te są aktualizowane.

I tak to się w tym IT/security kręci…

UPDATE: To nie jest tak, że powstał ten wpis i over. Założyłem kolejne issue, na wypadek gdyby autor przeoczył wcześniejsze. Napisałem też maila. Póki co cisza.

Google Authenticator ma backup

Piekło zamarzło. Przedwczoraj na blogu ogłoszono, że Google Authenticator dorobił się backupu kodów na koncie Google. Wersja oferująca tę funkcjonalność jest już do pobrania z Google Play. To duża i ważna zmiana i okazja do notki. Przy okazji zmieniła się niestety ikona programu.

Jak działa TOTP?

Zasada działania TOTP (Time-based One-Time Passwords) jest bardzo prosta, a implementacja w większości języków to kilka-kilkanaście linii kodu. W skrócie: najpierw, przy włączaniu tej metody uwierzytelniania, serwer generuje i zapisuje sekret. Dzieli się nim z użytkownikiem, zwykle przy pomocy QRcode.

Od tej pory kody są generowane na podstawie bieżącego czasu (unix timestamp), zaokrąglonego do 30 lub 60 sekund, oraz ww. sekretu. Najpierw są hashowane, następnie hash jest przekształcany na sześciocyfrowy kod. I już.

Jak widać, do generowania kodów dla danego użytkownika wystarczy poznać sekret. Natomiast z uwagi na użycie funkcji skrótu, odtworzenie sekretu z kodu jest bardzo trudne. Sprytne.

Znaczenie

Czemu to takie ważne? Brak jasnego, prostego sposobu backupów był dla mnie ogromnym argumentem przeciw korzystaniu z TOTP. Stosunkowo łatwo było stracić dostęp do kodów, czyli odciąć się od serwisu. A dostępność jest przecież składową bezpieczeństwa. Dlatego wolałem jako 2FA wykorzystywać kody SMS. Mocno niedoskonałe: drogie, niewygodne, zawodne, podatne na ataki. Oczywiście koszt jest po stronie serwisu, który musi wysyłać kody. Wygoda to rzecz dyskusyjna, niektórzy dostawcy nawet nie mieli dużego opóźnienia w dostarczaniu SMSów. Awarie operatorów nie zdarzały się często, a SIM swap nie jest tanim czy łatwym atakiem.

Oczywiście istniały alternatywne aplikacje, które oferowały backup sekretów. Tylko jakoś bardziej ufam dostawcy systemu operacyjnego na moje urządzenie, niż losowej appce. Podejrzewam, że ludzi takich jak ja było więcej.

Jak było wcześniej?

Wcześniej było… słabo. Z backupem Google Authenticator można było sobie radzić na kilka sposobów. Pierwszym było zdjęcie/screenshot QRcode przy włączaniu TOTP. Średnio wygodne w przechowywaniu (bitmapa/wydruk), zajmujące dużo miejsca, żeby wyszukiwać trzeba dobrze opisać.

Kolejny sposób to zapisanie kodów ratunkowych. Większość serwisów w momencie generowania sekretu TOTP podaje kody ratunkowe do wydrukowania/zapisania. Niezłe, o ile ktoś korzysta z managera haseł.

Ostatni sposób to… drugie urządzenie z Google Authenticator i utrzymywanie kodów na obu urządzeniach. Dość drogie z uwagi na koszt kolejnego urządzenia, niezbyt wygodne z uwagi na konieczność ręcznej synchronizacji.

Jak widać, powyższe sposoby są niezbyt wygodne, albo działają dla osób, które mają dobrze poukładane backupy. Dla osób, które po prostu chcą mieć zabezpieczone konta przez 2FA, a niekoniecznie chcą projektować system backupów, uwzględniając jego dostępność – bardzo średnie. Bo właśnie, fajnie, że masz wydrukowane QRcode’y czy kody ratunkowe przechowywane w sejfie. Ale co jesteś właśnie na wakacjach i tracisz telefon, wraz z dostępem do wszystkich serwisów?

Wady

Obecne rozwiązanie nie jest idealne. Nadal będziemy uzależnieni od Google w kwestii backupu kodów i ich odzyskania. Dla większości ludzi będzie to zapewne akceptowalne ryzyko, tym bardziej, że ma znaczenie wyłącznie przy odzyskiwaniu, czyli bardzo rzadko.

Kolejną wadą jest trzymanie wszystkich jajek w jednym miejscu. Konto Google staje się SPOF. Szczególnie, jeśli ktoś korzysta także z zapamiętywania haseł przy pomocy Google.

Jeszcze osobną sprawą jest kwestia zaufania do samego Google. Nie napisałem tego pierwotnie i wprost, ale uznałem, że jeśli mamy OS od Google, zintegrowany z ich sklepem i konto w ich serwisie, to z jakiegoś powodu ufamy Google. Zależy oczywiście od modelu zagrożeń.

Zaufanie do Google jest tym istotniejsze, że backup kodów trafia do Google w postaci niezaszyfrowanej. Czy Google udostępni np. służbom kody 2FA? Nie wiem, ale się domyślam. Po raz kolejny, kwestia modelu zagrożeń. Szczęśliwie Google zapowiedziało dodanie szyfrowania.

Podsumowanie

Uważam tę zmianę za bardzo dobrą, z punktu widzenia przeciętnego użytkownika i mam nadzieję, że przyczyni się do popularyzacji 2FA. W ogóle ostatnio mamy dobry klimat dla 2FA opartych o TOTP. Najpierw wyłączenie 2FA przy pomocy SMSów w Twitterze, teraz backupy w Google Authenticator.

Paradoksalnie jednak, po tej zmianie może się okazać, że… lepiej zmienić dostawcę appki do 2FA, niż włączać backup do chmury Google w Google Authenticator. W sugerowanych pojawiły się FreeOTP, FreeOTP+, 2FAS.

UPDATE: Dodane info o zaufaniu do Google. Dodane info o braku szyfrowania i zapowiedź dodania. Zaktualizowane podsumowanie.