Skutki wycieku danych z Morele.net

Jakiś czas temu ze sklepu internetowego Morele.net wyciekły dane. W sieci zaroiło się od reakcji, dość skrajnych. Od psioczenia na słabe zabezpieczenia i „jak tak można było” i „pójdę z tym do sądu” po „nie stało się nic„.

Wyciekły maile, imiona, nazwiska, numery telefonów dla 2,2 mln kont. Oraz prawdopodobnie, dodatkowo, jak twierdzi włamywacz, a czemu zaprzeczyły Morele.net, numery PESEL oraz skany dowodów osobistych dla kilkudziesięciu tysięcy kont, a włamywacz ujawniał kolejne szczegóły na Wykopie (konto już usunięte).

Moim zdaniem prawda leży, jak to często bywa, gdzieś pośrodku. Na pewno wyciek jest ważny ze względu na skalę – 2,2 mln rekordów w skali Polski to bardzo dużo[1], w dowolnym aspekcie – czy to do wysyłki spamu, czy do ataków phishingowych przy pomocy SMSów, czy wreszcie jako baza haseł, zarówno do próby bezpośredniego wykorzystania ich w innych serwisach, jak i do analizy i budowy słowników w kolejnych atakach.

W informacjach o wycieku poruszony był aspekt niezłego hashowania haseł. Niestety te niezłe hashe w praktyce niewiele wnoszą – być może nie uda się złamać, w sensownym czasie i sensownym kosztem, najtrudniejszych haseł, ale najsłabsze ok. 20% można złamać na CPU na pojedynczym komputerze w ciągu pojedynczych godzin.

Jeśli informacja o wycieku skanów dowodów jest prawdziwa, to jest to dla ofiar spory problem – możliwości do nadużcia spore, PESEL w zasadzie niezmienialny, a wymiana dowodu kłopotliwa. Przypuszczam, że chodzi tu tylko o kupujących na raty.

Pozostałe 2,2 mln niespecjalnie ma powody do zmartwień, jeśli tylko nie stosuje schematycznych haseł oraz ma osobne hasła do różnych serwisów. W tym miejscu gorąco polecam programy do przechowywania haseł w stylu Keepass.

Jeśli hasła są różne w różnych serwisach to nawet ich siła nie ma specjalnego znaczenia, o ile w serwisie są tylko dane z bazy, nie można zrobić zakupu itp. OK, atakujący dostanie się do konta w sklepie internetowym. Co zobaczy, czego jeszcze nie wie? Historię zakupów? Ironizuję, ale zakładam, że nie jest w stanie robić zamówień itp. bez dodatkowego potwierdzenia. Mógł za to usunąć konto, jednym kliknięciem, bez potwierdzania. Cóż, to strata głównie dla sklepu – jeśli ktoś potrzebuje to założy nowe konto…

Jeśli chodzi o maile, to jest spora szansa, że już wcześniej trafiły do baz spamerów i marketerów. Chyba, że ktoś stosuje oddzielne aliasy do serwisów, ale wtedy zupełnie nie ma problemu – wystarczy usunąć alias. Podobnie z numerami telefonów. A jeśli ktoś chce mieć święty spokój, to przypominam, że usługi GSM tanieją i numer telefonu płatny w formie prepaid można mieć już za 5 zł rocznie i używać go w różnych mniej istotnych miejscach. Oczywiście można to zrobić w nowocześniejszy sposób.

Tu dochodzimy do sedna: czy do zakupu w każdym sklepie internetowym faktycznie potrzebne jest zakładanie konta? Niektóre sklepy wymuszają założenie konta, ale staram się takich unikać, a z paru zakupów zdarzyło mi się zrezygnować z tego powodu. Jeśli już zakładamy konto, to dobrze by było, żeby wymagane było podawanie jak najmniejszej ilości danych. Zupełnie dobrze by było, gdyby serwisy pozwalały na ustawienie po jakim czasie nieaktywności usunąć konto lub chociaż cyklicznie przypominać mailem o takiej możliwości.

[1] Kolejny duży polski wyciek, który kojarzę to ~700 tys. z Filmweb. Oczywiście polskie konta występują też na wyciekach światowych i będą to porównywalne ilości.

UPDATE: Wpis nieco przeleżał jako szkic i został ostatecznie opublikowany w formie nieco pociętej. Mimo tematu, który pozostał z wersji oryginalnej, celowo pominąłem m. in. spekulacje nt. skutków dla Morele.net i chciałbym, aby tak pozostało, również w komentarzach.

Jakość niektórych narzędzi security Linuksie

Był sobie ciekawy wpis dotyczący siły haseł i narzędzi do automatycznego jej sprawdzania. Szykowałem się do dokładniejszej zabawy i testów, ale jakoś się rozeszło po kościach, więc krótko o tym, co zauważyłem.

Wnioski na temat jakości narzędzi do generowania haseł i automatycznego sprawdzania nie są zbyt optymistyczne. Narzędzia do haseł mają błędy. Smutne błędy. Spójrzmy na następujące wynik dotyczące haseł wygenerowanych przez pwgen i sprawdzanych cracklib-checki. Za każdym razem generowane było 100 tys. haseł, o zadanej długości (poczynając do 10 i kończąc na 20). Liczba podaje, ile nie było OK wg cracklib-check.

LANG=C pwgen -s -1 10 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
79LANG=C pwgen -s -1 11 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
122LANG=C pwgen -s -1 12 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
16LANG=C pwgen -s -1 13 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
27LANG=C pwgen -s -1 15 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
59LANG=C pwgen -s -1 16 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
98LANG=C pwgen -s -1 17 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
141LANG=C pwgen -s -1 18 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
215LANG=C pwgen -s -1 19 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
275LANG=C pwgen -s -1 20 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
373

Jak widać, ilość słabych haseł spada, osiągając minimum w okolicy dwunastoznakowych, by następnie systematycznie rosnąć. Rzut oka na generowane hasła i… wszystko jasne:

HiGFYedy6gHG: it is too simplistic/systematicnowuTUtOon4W: it is too simplistic/systematicO4rstUX43Bef: it is too simplistic/systematic1mMTsIHZyHIH: it is too simplistic/systematicSeVw3MnMnOpp: it is too simplistic/systematic

Domyślnie(?) cracklib-check uznaje powtórzenie znaków za oznakę słabego hasła. Kurtyna.

Kolejne narzędzie, które znam, lubię i którego używam często (zwykle modyfikując wynik, jednakowoż) to gpw. Okazuje się, że posiada ono brzydki błąd, który powoduje, że czasami hasło nim wygenerowane jest krótsze, niż planowaliśmy, tj. niż podane w stosownym parametrze. Przykład: 100 tys. haseł szesnastoznakowych (niby!):

gpw 100000 16 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -v ': OK' | grep -i shortaqs: it is WAY too short

I hasło typu aqs. Jest nawet zgłoszony błąd w Debianie w tej sprawie. Też mam mieszane uczucia co do poziomu istotności błędu, ale… sprawdzanie długości otrzymanego wyniku to przecież trywialna sprawa, więc jakie inne błędy może mieć soft?

Ogólnie: mam wrażenie, że nie warto zbytnio ufać gotowym narzędziom. Może nawet nie to, żeby od razu pisać coś własnego, ale warto sprawdzić gotowce (bezpieczne! wolnoźródłowe!), nim się z nich skorzysta.

Dziura w OpenSSL, o jakiej się nie śniło

No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda „tylko” 64kB i „tylko” związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy… Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).

Heartbleed

Źródło: http://heartbleed.com/

Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś – wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.

Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.

Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał… false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób… Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.

Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.

Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty – ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).

Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.

UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:

lsof -n | grep ssl | grep DEL

Konto z premią BGŻ.

Karta kredytowa

Źródło: karta kredytowa.

Jakiś czas temu mBank wprowadził opłatę za kartę, co sprawiło, że zacząłem szukać alternatyw. Mieli też parę innych wtop od tamtego czasu i w zasadzie gdyby nie świetne płatności online, to dawno bym się z nimi zupełnie pożegnał.

Pierwszą alternatywą na darmowe konto z darmową kartą[1], którą znalazłem było konto dbNET, które założyłem rok temu i z którego – jako konta do karty – jestem zadowolony. Zawsze jednak chciałem mieć więcej, niż jedną kartę – i można mieć grosze na niej, więc mniejszy problem, jak zginie, i zawsze można nią zapłacić w przypadku awarii systemu w jednym banku.

Teraz, po tym jak w czasie Euro 2012 byłem bombardowany reklamą z wiewiórkami, przypomniałem sobie o tym, że BGŻ miał w ofercie konto z premią, które rozważałem jako drugą alternatywę dla mBanku. W zasadzie wtedy było to konto z podwyżką, czyli inny produkt ale różnica jest kosmetyczna i minimalna.

Nie jest to dokładnie wariant polegający na niepłaceniu i braku dodatkowych warunków, bo miesięczna opłata za kartę wynosi 8 zł (obniżana do 5 zł przy płatnościach kartą za min. 300 zł), ale przynajmniej po spełnieniu wymagań (czytaj zrobieniu questa) można nie tylko nie stracić, ale wręcz zarobić parę zł.

Konkretnie: prowadzenie zero zł, wypłaty z wszystkich bankomatów w Polsce za darmo, przelewy przez internet za darmo, opłata za kartę 8 zł miesięcznie (5 zł w przypadku płatności kartą za min. 300 zł). Od najwyższej wpłaty, która wpływa na konto (nie musi to być wynagrodzenie/emerytura/renta – źródło: pracownik banku) otrzymujemy 1 zł za każde wpłacone 100 zł, ale nie więcej niż 50 zł, o ile dokonamy 3 płatności kartą. Czyli szykuje się matematyka i konieczność pamiętania ile razy płaciliśmy i ile w sumie wydaliśmy, czyli quest, którego pierwotnie chciałem uniknąć: minimum 3 płatności za minimum 300 zł, aby otrzymać premię (do 50 zł) i zapłacić 5 zł za kartę. Przy wpływie 2000 zł i nazwijmy to aktywnym korzystaniu zarobimy na czysto 15 zł, przy wpływie 5000 zł – 45 zł. No to mnie przekabacili tymi paroma zł…

Dokładna recenzja konta z premią jest tutaj, ale parę subiektywnych odczuć opiszę sam. Konto założyłem w oddziale, bo i tak miałem parę pytań dodatkowych (są wersje zdalne). W oddziale raczej kolejki i nie chciałbym musieć korzystać do wypłat (nieodparte skojarzenie z kolejkami na poczcie), na szczęście nie była to kolejka do stanowisk z zakładaniem kont. Zakładanie i aktywacja karty bardzo proste, nie trzeba dzwonić i męczyć się z IVR. Logowanie do systemu przez internet takie dla ludzi – można samemu określić login i hasło (są pewne ograniczenia). Pewnie potencjalnie niezbyt bezpieczne, ale za to wygodne. Lepiej, niż w mBanku (narzucony login) i w DB (narzucony login i numeryczne hasło). Kartę przysłali szybko i dają do wyboru różne opcje aktywacji (wybrałem przysłanie karty i aktywację SMS). Zobaczymy jak to wszystko działa w praktyce (przewidywane aktualizacje wpisu).

Taka jeszcze uwaga ogólna – 3 banki jednocześnie to chyba maksimum, które jestem w stanie tolerować. Chętnie bym tę liczbę zredukował do dwóch, ale przelewy online mBanku wydają się póki co niezastąpione. Zobaczymy jeszcze jak to w BGŻ wygląda w praktyce…

[1] Nie ma darmowych obiadów, chodzi o wariant maksymalnie zbliżony do darmowego, bo pełne zero zł, bez żadnych warunków dodatkowych typu ilość transakcji, kwota transakcji czy określone wpływy za prowadzenie i kartę ciężko znaleźć.

UPDATE: Karta MasterCard, którą dają dają do konta z premią to wersja tradycyjna, nie zbliżeniowa. Dla mnie – i pewnie dla większej grupy paranoików – zaleta, bo coraz trudniej takie coś dostać, w niektórych bankach wręcz nie są dostępne.

UPDATE: Wyświetlanie historii operacji na koncie jest skopane – nie wiem czemu, ale jest głupie ograniczenie czasu objawiające się komunikatem Zakres nie może przekraczać 31 dni.

Zakładanie konta dbNET – wrażenia.

Karta kredytowa

Źródło: karta kredytowa.

Ponieważ mBank wprowadził opłaty za kartę, co wyjątkowo mi się nie spodobało i się najprawdopodobniej niebawem pożegnam przynajmniej z ich kartą, postanowiłem założyć inne konta. Jako pierwsze, zostało wybrane konto dbNET Deutsche Banku (dead link) – to co w mBanku do tej pory, czyli zero opłat za prowadzenie, przelewy przez Internet oraz kartę debetową pod warunkiem 1 transakcji kartą miesięcznie (w przeciwnym wypadku 5 zł miesięcznie za kartę). Do tego bezpłatne wypłaty z bankomatów na całym świecie i – jeśli komuś zależy – wygląda, że lepsze oprocentowanie.

Ponieważ miałem parę pytań, udałem się do placówki. Pierwsza informacja od pracownika banku – za transakcję uznawana jest także wypłata gotówki w bankomacie. Miłe i czyni pilnowanie transakcji totalnie bezproblemowym – wypłaty z bankomatów to podstawowa funkcja z której korzystam. Oczywiście zobaczymy, jak będzie w praktyce, ale jedne zakupy też mogę kartą zrobić.

Druga informacja, tym razem negatywna – konto trzeba załatwiać przez Internet i kuriera. Bardzo nie na rękę, bo chciałem założyć na miejscu – oddział mam blisko, z adresami lekkie zamieszanie i przeczucie, że z kurierem będą problemy. Dostałem radę, żebym założył na stary adres, jako adres odbioru podał korespondencyjny, a potem zmienił korespondencyjny. Na szczęście nie było to potrzebne – procedura dopuszcza podanie adresu odbioru przesyłki jako niezależnego od adresu stałego zameldowania i adresu korespondencyjnego. Nie rozumiem, czemu nie ma możliwości założenia tego konta w oddziale, bo podczas paru wizyt (kumpel załatwia często sprawy po drodze, więc bywam) liczba pracowników przewyższała tam liczbę klientów…

Trzecia informacja, również negatywna – nic nie wiedzą o wprowadzeniu haseł jednorazowych przesyłanych przez  SMS. A gdzieś na jakimś forum/blogu, szukając informacji o tym koncie wygooglałem, że taka funkcjonalność jest planowana w sierpniu. Zamiast tego jest karta TAN, której idea mi się nie podoba (ale o tym później/innym razem).

Wypełniłem wniosek przez Internet – całkiem przyjemne, jedyna wada to fakt, że przy końcu pyta o potwierdzenie zaznajomienia się z kilkoma dokumentami (PDFy, kilkadziesiąt stron). Przeczytanie tego zajęło dłuższą chwilę, po czym po zatwierdzeniu i wybraniu kontynuacji okazało się, że „uzupełnij dane”, a wszystkie wprowadzone do tej pory dane są wyczyszczone. Irytujące, szczególnie, że zakładają, że ludzie i tak nie przeczytali dokumentów – w mailach otrzymanych później znowu zachęcają do przeczytania tychże PDFów, więc wymóg zatwierdzenia taki trochę od czapy.

Nie pomyliłem się co do problemów z kurierem. Przedstawiciel InPost zadzwonił w piątek i umówił się na sobotę, po czym zwyczajnie nie przyszedł, nawet nie racząc odwołać wizyty (a był proszony o telefon przed, żebym – na wypadek gdybym wyszedł, zdążył wrócić). Po paru dniach zadzwoniła pani z InPost, że mają przesyłkę i że… „adresat był nieobecny”. Ta jasne. Ostatecznie, zamiast w sobotę, to w środę, udaje się im dostarczyć przesyłkę.

Pora na aktywację. Rzut oka na instrukcję (przejrzysta i dobrze opisana), telefon na podany numer, w sensowny IVR, szybkie połączenie z konsultantką, seria durnych pytań (imię i nazwisko, choć przed chwilą się przedstawiłem), ale taka procedura. Skupić się i nie dywagować (na pytanie czy ma Pan konto w naszym banku odpowiadam twierdząco w ostatniej chwili gryząc się w język i hamując jeszcze nie, właśnie jestem w trakcie zakładania; niech wasza mowa będzie tak, tak, nie, nie). Kod dwa razy. Rozłącz. Poniżej 5 minut. Nieźle, biorąc pod uwagę, że wysłuchiwałem całego IVRa.

Próba zalogowania przez net z użyciem świeżo założonego kodu zakończona porażką: Niepoprawne dane do autoryzacji / Authorization fault, nara. Co ciekawe NIK ma 10 cyfr (ciekawe czy kiedykolwiek nauczę się go na pamięć), kod dostępu 6 – trochę mało, szczególnie, że muszą być cyfry, dokładnie 6 i tylko cyfry. Mało i szkoda, że nie ma liter – te łatwiej zapamiętać. No ale 6 „losowych” cyfr nie jest problemem.

Nie ruszyło aż do następnego dnia. Ponowny telefon (sobota przed 8 rano) i ponowne ustawienie kodu. Łączny czas połączenia – lekko ponad 3 minuty. Tym razem mogę się zalogować. Dziwne, bo kod dokładnie ten sam, wymyślony wcześniej, więc raczej nie zrobiłem błędu. Niestety, po zalogowaniu widzę Internet service is currently unavailable. Wszystko po angielsku, próba przełączenia polski lub niemiecki nie działa. Nieszczęścia chodzą najwidoczniej parami, mBank nigdy, przez parę lat korzystania mi czegoś takiego nie odwalił.

Po paru godzinach próbuję zalogować się ponownie. Tym razem działa. Obejrzałem sobie, nie wygląda źle, zobaczymy jak będzie w praktyce. Niestety, tym razem znowu bug – mało profesjonalnie (eufemizm) wygląda debetowa, ???pl_PL.kartSUOLista.status.P??? jako rodzaj karty.

Pierwsze wrażenie – tylko 3/10. Niezłe przemyślenie i przygotowanie zepsute jest niestety przez wykonanie, a problemy z serwisem przy koncie internetowym przepełniają czarę goryczy. Jak konto mBanku był przez lata jedynym bankiem, tak konto dbNET na pewno nie dostanie takiej szansy po tym wstępnie.

UPDATE: Aktywowałem też kartę i kody TAN (w sumie bez sensu była aktywacja samego konta, tyle że sobie pooglądałem). Nie sprawdzałem jeszcze, czy działa, ale co ciekawe, tym razem zostałem poinformowany, że kod dostępu może „ruszyć” dopiero jutro po 8 rano „bo jest po 18 już i może to nie zadziałać dziś”. Co wyjaśnia problemy opisane 3-4 akapity wyżej. Czas aktywacji: 6 minut.

Zniknął też podany dziwny komunikat nt. stanu karty, jest trochę lepsze (ciekawe czy wynikające z aktywacji) debetowa, Production in progress. Tylko trochę, bo i po angielsku, i niezupełnie zgodnie ze stanem faktycznym (no dobra, niech będzie, że „się aktywuje”).

Jakby tak było od razu to 5/10. Przydałoby się trochę dopracować procedury…

Niebezpieczny świat.

Ostatnie wydarzenia coraz bardziej skłaniają mnie do – paranoicznego, przyznaję – wniosku, że żadne dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie. O ile tylko komuś będzie zależało.

Na początek – hasła. Niektóre portale, jak Allegro, trzymają hasła otwartym tekstem. Niezależnie od podjętych środków bezpieczeństwa, przy takim podejściu wyciek tych haseł jest IMHO kwestią czasu.

Wiele nie zmienia trzymanie skrótów (hashy) haseł. Ostatnio – poza małymi wyciekami polskimi typu JPwyciekły hashe haseł z Gawkera i niesolone hashe haseł z FSF. To drugie jest wielką porażką, bo mówimy o środowisku z – teoretycznie – wysoką świadomością dotyczącą bezpieczeństwa i spraw technicznych, a tymczasem korzystano z najsłabszej funkcji skrótu i w najgorszym wydaniu. Powinno być najlepiej, było najgorzej. Klasyczne szewc bez butów chodzi.

Zresztą, pomału można zacząć stawiać znak równości między wyciekiem hashy haseł (zwł. niesolonych), a wyciekiem samych haseł – crackery MD5 są coraz szybsze. Co prawda to tylko benchmark, ale najnowsza wersja crackera whitepixel, który podobno jest chyba obecnie najszybszy, sprawdza 33 miliardy (nie miliony, miliardy) kombinacji na sekundę (dla pojedynczego hasha). Na potężnym, co prawda (4 dwurdzeniowe GPU; 1,2 kW poboru prądu przy obciążeniu, 2700 USD w tej chwili), ale pojedynczym komputerze PC.

Inne funkcje skrótu też nie są wiele lepsze. SHA1 to wg tego benchmarku w tym momencie 390 milionów kombinacji na sekundę, oczywiście na pojedynczej maszynie. A przecież bez problemu można mieć tych maszyn więcej, i to za niewielkie pieniądze.

Ale nie tylko haseł się to tyczy. Dane, które nie powinny ujrzeć światła dziennego wyciekły z „wewnętrznego”, rządowego systemu. Oczywiście mowa o wikileaksowym Cablegate. Swoją drogą ciekawe, jak długo w tych okolicznościach w stanie nieujawnionym pozostanie polisa Wikileaks (dead link)?

Głośno też było o rzekomym backdoorze w OpenBSD, a konkretniej IPSEC, który miało zamieścić FBI 10 lat temu (celowo nie linkuję, AFAIK rozeszło się po kościach i backdoora nie było, ale nie śledziłem). Co nie jest takie niemożliwe, bo korzystając z różnych „dziwnych” właściwości matematyki, da się zmusić algorytm szyfrujący, by „wyciekał” klucze. W mało zauważalny sposób – na przykład 128 bajt zaszyfrowanej wiadomości, przexorowany przez arbitralny klucz, będzie ujawniał klucz, którym była szyfrowana cała wiadomość. Albo coś na podobnej zasadzie – sky – i wiedza matematyczna – is the limit.

I raczej nie wierzę w to, żeby programista – czy użytkownik, który zwykle nie ma wielkiej wiedzy matematycznej/kryptograficznej, był w stanie coś takiego zauważyć. Przykład tego widać było przy dziurze w OpenSSL w Debianie. Efekt był dość spektakularny – do każdego konta umożliwiającego logowanie SSH po kluczach można się było dostać przy – IIRC – maksimum 65 tys. prób (bo tylko tyle różnych kluczy było generowanych). Na dowolnym systemie. O ile tylko klucz publiczny użytkownika był generowany na podatnym Debianie.

Niedowiarkom przykład ciekawych właściwości matematycznych można łatwo i zrozumiale zaprezentować na przykładzie listy 18 ulubionych filmów. Oto test (przetłumaczyłem na polski, z wyjtkiem tytułów, polecam IMDB):

Zrób test i dowiedz się, jaki film jest twoim ulubionym. Ten prosty matematyczny quiz przewiduje, który z 18 filmów spodoba ci się najbardziej. Nie pytaj w jaki sposób, ale to działa!

  • Wybierz cyfrę z zakresu 1-9.
  • Pomnóż ją przez 3.
  • Do wyniku dodaj 3.
  • Otrzymany wynik ponownie pomnóż przez 3.
  • Zsumuj obie cyfry otrzymanej liczby. Wynik to numer twojego przewidzianego ulubionego film na poniższej liście:

Lista filmów:

  1. Gone With The Wind
  2. E.T.
  3. Blazing Saddles
  4. Star Wars
  5. Forrest Gump
  6. The Good, The Bad, and the Ugly
  7. Jaws
  8. Grease
  9. The Joy of Anal Sex With A sheep
  10. Casablanca
  11. Jurassic Park
  12. Shrek
  13. Pirates of the Caribbean
  14. Titanic
  15. Raiders Of The Lost Ark
  16. Home Alone
  17. Mrs. Doubtfire
  18. Toy Story

W zasadzie koniec mijającego roku widzę trochę na zasadzie do kogóż to włamano się dzisiaj? I to tylko patrząc na najgłośniejsze i ujawnione sprawy i dziury (taki wariant minimum dla administratora – trochę wypada się w security orientować)…

Korzystając z okazji – bo to ostatni wpis, życzę wszystkim użytkownikom komputerów (ze specjalnym uwzględnieniem adminów) w nadchodzącym Nowym Roku mniej dziur bezpieczeństwa i awarii.

UPDATE: Paranoje dotyczące postępującej szybkości łamania hashy studzi ten wpis o przechowywaniu haseł. Polecam.

Jak często powinny występować cyfry w kodzie jednorazowym?

Wszystko zaczęło się od tego wpisu, którego głównym bohaterem jest paradoks urodzin, a który przeczytałem niedawno. Kto by pomyślał, że wybierając losowo (tylko) tysiąc liczb ze zbioru (aż) czterech milionów liczb mamy (aż!) 10% szans na to, że wybrane liczby się powtórzą? Co prawda nie liczyłem samodzielnie, ale wynik wygląda na prawidłowy. WolframAlpha co prawda wymięka dla czterech milionów, ale dla jednego miliona liczy i wychodzi ok. 39%.

Przypomniało mi się niedawne narzekanie – nie pamiętam niestety czyje – że w hasłach jednorazowych przysyłanych przez mbank SMSem takie same cyfry występują obok siebie się zbyt często, więc chyba generator pseudolosowy jest słaby czy też wręcz zepsuty. Jak mi się przypomniał ten temat, to postanowiłem policzyć prawdopodobieństwo zdarzenia, że SMS, który dostaliśmy, zawiera hasło jednorazowe z powtarzającymi się obok siebie cyframi.

Cyfr w przysyłanym haśle jednorazowym jest osiem. Prawdopodobieństwo, że cyfra kolejna jest różna od cyfry poprzedniej wynosi dokładnie 0,9. Czyli, żeby cyfry się nie powtarzały, to druga musi być inna, niż pierwsza, trzecia inna, niż druga, …, i na koniec ósma inna, niż siódma. Pierwsza cyfra nie ma się z czym powtarzać, oczywiście.

Prawdopodobieństwo zdarzenia, że wszystkie cyfry są różne wynosi zatem dla ośmiocyfrowego hasła jednorazowego 0,9^7 (pierwsza cyfra nie ma znaczenia, bo nie ma się z czym powtarzać) czyli 47,83%. Jaka jest zatem szansa, że cyfry się koło siebie powtórzą? Oczywiście prawdopodobieństwo odwrotne, czyli 1 – 0,9^7. Czyli 52,17%. Zatem, jeśli wszystkie cyfry mają takie samo prawdopodobieństwo wylosowania na wszystkich pozycjach (a tak teoretycznie być powinno), to częściej dostaniemy hasło jednorazowe, gdzie mamy powtarzające się cyfry koło siebie, niż takie, w którym się nie powtarzają. Nie ma to oczywiście nic wspólnego z pierwotnym paradoksem urodzin, ale jest ciekawe.

Nawiasem, prawdopodobieństwo, że którekolwiek cyfry w otrzymanym haśle jednorazowym się powtórzą (niekoniecznie obok siebie) wynosi aż 98% (i to już liczymy wykorzystując wzór do paradoksu urodzin).

Jak mieć bezpieczne hasło i nie popaść w paranoję?

Za sprawą włamania na Wykop wywiązała się dyskusja o hasłach. Pisali o tym groszek (dead link), kUtek, Zal i generalnie z żadnym zaprezentowanym podejściem do końca nie mogę się zgodzić.

Jak dla mnie wszystkie te zabawy ze skrótami itp. są nie do przyjęcia. Albo hasło jest takie, że trzeba je pamiętać (czyli umieć wpisać z głowy), albo można sobie pozwolić na jakiś portfel haseł (i wtedy nie ma się co bawić, tylko można wygenerować losowe). Hasłami losowymi nie ma się co zajmować – mają być długie i możliwie losowe.

Pozostają hasła do zapamiętania. Tu trzeba rozróżnić serwisy krytyczne (także maile, na które mamy ustawione przypominanie haseł) i resztę. Krytyczne łatwo wyróżnić – możliwe większe straty finansowe, wycieki prywatnych danych itp. Pierwsza sprawa, to – jeśli to tylko możliwe – do serwisów krytycznych chronimy także login. Po co? Prosta sprawa, jeśli ktoś będzie chciał nam zrobić kuku, to nie ma co ułatwiać mu sprawy. Plus, niektóre serwisy (zwł. banki) mogą blokować po określonej ilości nieudanych logowań, więc źli ludzie mogą nam uprzykrzyć życie już samą znajomością loginu.

Poza tym, do serwisów krytycznych mamy możliwie mocne, nieschematyczne hasła, które pamiętamy, logujemy się możliwie tylko z zaufanych maszyn i w sposób bezpieczny (nie plain text), nie 20 zakładek na innych portalach otwartych w tym czasie. Jeśli zdarzy nam się logowanie awaryjne z niezaufanej maszyny/niebezpiecznym protokołem – jak najszybciej wymieniamy hasło (z bezpiecznej maszyny). Reszta w rękach admina serwisu. No może jeszcze nie chwalimy się zbytnio, które serwisy są dla nas krytyczne. 😉

Reszta, czyli serwisy niekrytyczne. Tak naprawdę zwykły użytkownik może zrobić tylko trzy rzeczy. Pierwsza, absolutnie konieczna: nie stosujemy takich samych haseł. Przy akcjach jak ta z Wykopem i podobnych, w razie czego włamywacz uzyska dostęp do jednego serwisu. Po takich włamaniach zwykle włamywacz automatem sprawdza, czy można zalogować się z takim samym loginem i hasłem na inne portale (chyba, że darzy nas szczególną uwagą, ale to trochę inna sprawa).

Jeśli chodzi o hasła, reszta to sprawy wtórne – jeśli stosujemy schemat/schematy to po takim włamie włamywacz raczej nie będzie miał dostępu do danych z kilku serwisów (chyba, że darzy nas szczególną uwagą, albo jedna i druga baza wpadną w ręce kogoś, kto nas darzy). Oczywiście warto zmieniać hasła okresowo i mieć różne schematy/hasła, ale wygoda kłóci się z bezpieczeństwem.

Sprawa druga: ustawiamy przypominanie/zmienianie hasła na zaufanego maila. W razie włamu przyda się do odzyskania dostępu, choćby po to, żeby zamieścić sprostowanie.

Sprawa trzecia, nieoczywista. Nie ufamy niekrytycznym portalom. Koniec, kropka. Mogą być poziomy dostępu (jak na Joggerze) ale nie znaczy to, że zamieszczone na wyższym poziomie dane są/będą niedostępne dla innych ludzi. Można to traktować jako kosmetykę, ale pisanie tam rzeczy, których nie napisało by się na stronie głównej to proszenie się o potencjalne kłopoty. Generalnie im mniej prywatnych/wrażliwych danych na takich serwisach, tym lepiej.

Trzeba przyjąć, że włamy itp. na serwisy niekrytyczne będą się zdarzały – przy ich ilości jest to jedynie kwestia czasu. I raczej będą to ataki na bazę serwisu, niż na nasze konto (chyba, że ktoś darzy nas szczególną uwagą), dlatego hasło należy mieć nieoczywiste, długie (dodanie przedrostka w stylu abcdefg (oczywiście nie chwalimy się nim) drastycznie wydłuży czas łamania hasła, jeśli ktoś nas „polubi”, ale IMO nie ma co popadać w paranoję. Co tak naprawdę się stanie, jeśli ktoś skorzysta z naszego konta do Wykopu (i tylko z niego)?

Po wykrytym włamaniu oczywiście zmieniamy hasło. Jeśli stosujemy hasła schematyczne, z oczywistym schematem, należy zmienić schemat i wymienić wszystkie hasła objęte danym schematem. Tyle dobrych rad, praktyka pokazuje, że kompromis między użytecznością a bezpieczeństwem zawsze jest trudny. Dlatego polecam określenie krytycznych serwisów i naprawdę dbanie o bezpieczeństwo w ich przypadku. W przypadku niekrytycznych i tak pewnie lenistwo AKA użyteczność AKA wygoda weźmie górę…