PINy, hasła – less is more

Będzie o PINach, a ogólniej o hasłach, bo PIN to specyficzny rodzaj hasła. Less is more to w tym przypadku mniej ograniczeń przekładających się na większe bezpieczeństwo. Zaczęło się od wpisu na Twitterze gdzie pokazano ograniczenia nakładane na PIN w pewnej aplikacji.

Zastanowiło mnie, czy da się policzyć o ile takie ograniczenia zmniejszą bezpieczeństwo, rozumiane jako przestrzeń możliwych poprawnych kombinacji PINu.

Na wstępie widać, że pierwsza cyfra PINu musi być inna niż 0 oraz 1. Już sam ten warunek zmniejsza przestrzeń poprawnych PINów o 20%. I to niezależnie od długości PINu.

Tu moja matematyka wysiada i sięgam po symulacje. Skrypt w Pythonie, który sprawdza wszystkie czterocyfrowe kombinacje i podaje, czy PIN jest poprawny (True) czy błędny (False) może wyglądać tak:

def is_valid(a, b, c, d):
    if a < 2:
        return False
    if ((a - b) == (b - c) or (b - c) == (c - d)):
        return False
    if (a == b) or (b == c) or (c == d):
        return False
    if ((b - a > 0) and (c - b > 0) and ((d - c > 0)) or (b - a < 0) and (c - b < 0) and (d - c < 0)):
        return False
    return True


for a1 in range(0, 10):
    for a2 in range(0, 10):
        for a3 in range(0, 10):
            for a4 in range(0, 10):
                result = is_valid(a1, a2, a3, a4)
                print(a1, a2, a3, a4, result)
python piny.py | grep -c True
5120

Jak widać, dla PINów o czterech cyfrach, wprowadzone ograniczenia zmniejszają przestrzeń dozwolonych PINów aż o niemal połowę.

Po co te ograniczenia i jak to zrobić poprawnie?

I teraz o motywacji. Jestem pewnien, że była ona szczytna i chodziło o podniesienie bezpieczeństwa. Jestem prawie pewien, że twórcy chodziło o wyeliminowanie prostych, schematycznych PINów. 0000, 1111, 1234 itp. Jak widać, w praktyce konsekwencje były dalej idące.

Najlepiej biorąc pod uwagę statystyki najczęściej występujących PINów i tworząc krótką listę PINów zabronionych. Wg statystyk PIN 1234 odpowiada za ponad 10% wystąpień wśród używanych PINów. 20 najczęściej używanych PINów jest używanych w 26% przypadków. Taka lista podniesie bezpieczeństwo, rozumiane jako „wymuszenie mało popularnego PINu” równie skutecznie, co proponowane ograniczenia. Zaś bezpieczeństwo rozumiane jako „ilość możliwych kombinacji” zostanie zmniejszone jedynie minimalnie.

Przypadki brzegowe

Jeśli przypuszczamy, że nasi klienci mają znacząco różne preferencje niż te z powyższych statystyk, robi się trudniej. W ogólności najlepiej walidować hasła na obecność zabronionych ciągów już w momencie ustalania hasła przez użytkownika. Zabronić można nazwy firmy, zasobu do którego jest chroniony dostęp, roku, czy popularnych ciągów znaków.

Jeśli jednak tego nie zrobiliśmy zawczasu, nadal nie wszystko stracone, choć robi się nieco ślisko. Nie znamy przecież PINów, co najwyżej mamy dostęp do hashy, więc ciężko będzie określić, których używają nasi klienci. Na ratunek przychodzi hashcat. Niezależnie od użytej funkcji hashującej, brute force krótkich PINów trwa moment. Jeśli korzystamy z bezpiecznych, wolno liczonych hashy, a użytkowników jest wielu, nie ma potrzeby robienia brute force wszystkich. Wystarczy analiza próbki statystycznej. Oczywiście taki audyt to operacja bardzo delikatna, więc nie zabieramy się za to bez stosownych umocowań i zachowania właściwej higieny.

UPDATE: Wersja uogólniona skryptu poniżej. Ilość cyfr w PIN regulowana ilością powtórzeń alfabetu w funkcji product. Dla dłuższych PINów warto skorzystać z pypy, które potrafi być szybsze.

import itertools
alphabet = list(range(0, 10))

def is_valid(i):
    if i[0] < 2:
        return False

    for n in range(0, len(i)-2):
        if i[n] - i[n+1] == i[n+1] - i[n+2]:
            return False

    for n in range(0, len(i)-1):
        if i[n] == i[n+1]:
            return False

    monotonic = True
    for n in range(0, len(i)-2):
        if (i[n] - i[n+1]) * (i[n+1] - i[n+2]) < 0:
            return True
    if monotonic:
        return False

    return True

for i in itertools.product(alphabet, alphabet, alphabet, alphabet):
    result = is_valid(i)
    print(i, result)

Cloudflare bez CAPTCHA

Wszystko zaczęło się od tego wpisu na blogu. W skrócie: Cloudflare chce zlikwidować CAPTCHA i zastąpić ją kluczami U2F.

Pomysł wydaje się ciekawy, bo wady CAPTCHA są znane. Zupełnie zgadzam się z tym, że i jest ona do obejścia, jeśli komuś zależy, i jest ona niewygodna. O tym ostatnim można przekonać się samodzielnie pisząc komentarz na tym blogu. Niedawno zmieniłem na blogu CAPTCHA na hCaptcha, z którego aktualnie korzysta Cloudflare.

Czy jednak rozwiązanie proponowane przez Cloudflare mające zapewnić internet bez CAPTCHA się przyjmie? Szczerze wątpię. Z punktu widzenia producentów kluczy U2F pomysł jest świetny. Ma też inną zaletę dla bezpieczeństwa w sieci. Może bowiem doprowadzić także do popularyzacji kluczy U2F i spadku ich cen. Kolejność dowolna.

Jednak automatyzacja, nawet mierna, w postaci jednej płytki SoC z ARM i wpiętego jednego klucza wydaje mi się niedocenianym zagrożeniem. Owszem, na blogu jest poruszone rozwiązanie z pijącym ptakiem, ale tego typu zagrożenie wydaje mi się niedoceniane.

Rozwiązanie nie musi być mechaniczne, co zwiększy jego niezawodność. Czy da się wpiąć wiele kluczy i korzystać z nich rotacyjnie? Zapewne będą takie próby. A może powstaną farmy pojedyncza tanich płytek z jednym kluczem? Zobaczymy. W tej chwili podobno serwisy rozwiązujące CAPTCHA zatrudniają ludzi w krajach o bardzo niskich wynagrodzeniach. Trochę nie wierzę, że płytka nie będzie tańsza.

Widzę też pewne zagrożenie dla prywatności, mimo zapewnień. Fizyczny, więc raczej trudny do wymiany identyfikator, nawet jeden z partii minimum 100 tys.? No niezupełnie dobrze to wygląda. Oczywiście nie pozwoli ustalić tożsamości użytkownika, ale czy zapobiegnie identyfikacji, że to ta sama osoba?

Niemniej pomysł uważam za ciekawy i będę śledził jego dalsze losy. Obecne CAPTCHA też są „łamalne”, a skoro nie będzie bez automatów, to może chociaż będzie wygodniej?

Automatyczne aktualizacje Debiana – HOWTO

Utrzymywanie aktualnych wersji oprogramowania to podstawa bezpieczeństwa. Nawet w przypadku zwykłego desktopa ma to znaczenie, szczególnie jeśli chodzi o przeglądarki internetowe. Pomóc w tym mogą automatyczne aktualizacje pakietów.

Tradycyjna, ręczna aktualizacja oprogramowania w Linuksie sprowadza się w większości dystrybucji do odświeżenia listy dostępnych pakietów i zainstalowania nowych wersji. Dla dystrybucji opartych o pakiety deb będzie to
apt-get update; apt-get dist-upgrade[1]

W dystrybucjach Linuksa takich jak Debian czy Ubuntu do dyspozycji mamy unattended upgrades, czyli mechanizm pozwalający na automatyczne aktualizacje pakietów. Pozwala on aktualizować wskazane pakiety bez ingerencji zarówno użytkownika, jak i administratora systemu. Poza samą aktualizacją umożliwia skonfigurowanie dodatkowych warunków, jak praca tylko przy podłączonym zasilaczu, wymuszenie rebootu systemu po aktualizacji pakietów, ograniczenie pasma przeznaczonego na pobieranie aktualizacji czy sprzątanie starych wersji kernela.

Aby włączyć mechanizm automatycznych aktualizacji, trzeba zainstalować pakiet unattended-upgrades. Dodatkowo należy wyedytować plik konfiguracyjny:
cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Samą konfiguracją działania automatycznych aktulizacji sterujemy przy pomocy zawartości pliku
/etc/apt/apt.conf.d/50unattended-upgrades.

Opcji jest wiele, od tego, które pakiety wykluczyć z aktualizacji, przez raportowanie mailem, czy wspomniane wcześniej limitowanie szybkości pobierania aktualizacji czy reboot systemu. Domyślna zawartość powinna być OK, jeśli korzystamy wyłącznie z podstawowych repozytoriów. W przypadku posiadania dodatkowych źródeł pakietów, warto sprawdzić czy będą one także aktualizowane i w razie potrzeby dostosować plik.

Przetestować działanie wprowadzonych zmian i ogólnie zachowanie możemy poprzez wydanie polecenia
unattended-upgrades -d

Pokaże ono, które pakiety zostałyby zaktualizowane w naszym systemie.

Trzeba pamiętać, że tego typu nienadzorowana aktualizacja zawsze niesie jakieś ryzyko niepowodzenia. Osobiście korzystam od lat na paru desktopach i nie napotkałem problemów. Jest tam jednak Debian w wersji stabilnej, przeważają repozytoria standardowe, a z dodatkowego oprogramowania są jedynie przeglądarki.

Na koniec polecam lekturę tego opisu automatycznych aktualizacji. Znajdziecie tam wiele dodatkowych szczegółowych informacji i przykładów.

[1] Dostępna jest też mniej inwazyjna wersja polecenia czyli apt-get update. Próbuje ona aktualizować tylko te pakiety, których aktualizacja nie wiąże się z usuwaniem ani doinstalowaniem innych pakietów. Ceną jest pozostawienie w dotychczasowej wersji pakietów, których nie da się zainstalować bez tej operacji. Więcej w manualu apt. Interesującym narzędziem do zarządzania pakietami jest opisywany kiedyś wajig.