Tag: hasło

Opublikowane w

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.

Opublikowane w

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
Opublikowane w

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.