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)
Szczeżuja namawiał, namawiał i w końcunamówił. Znaczy nie namawiał wprost, ale pisał o zaletach fediwersum i jakoś tak mnie zachęcił do założenia konta Mastodon[1]. Nie żeby trzeba było mnie specjalnie namawiać, bo od zawsze miałem słabość do alternatywnych rozwiązań i DIY. Nawet od dłuższego czasu produkcyjnie jest w użyciu Diaspora*.
Geneza
Czemu w ogóle wziąłem się za Mastodona, skoro jest Diaspora*, której używam od kilku lat? To, że Diaspora to niby bardziej Twitter, a Mastodon to niby bardziej Facebook nie miało znaczenia. Zresztą piszę „niby bardziej”, bo odnoszę dokładnie odwrotne wrażenie. Możliwe, że kwestia mojej instancji Mastodona, która limituje ilość znaków we wpisie do 500. Nie żeby mnie to jakoś bolało, ale Diaspora* chyba nie limituje. Przynajmniej nie zauważyłem. No ale może znowu może to być kwestia konkretnej instancji.
Poza tym, że lubię testować nowe rzeczy, poszło o ideę fediwersum i chęć sprawdzenia jak to działa w praktyce. Diaspora* niby umożliwia wymianę z innymi instancjami, ale robi to swoim własnym protokołem. Niespecjalnie przez coś innego używanym, jak zeznaje anglojęzyczna Wikipedia. Były plany implementacji Activity Pub, ale zostały porzucone. Brak wsparcia standardu Activity Pub źle wróży na przyszłość. No i nie ma tak ciekawych implementacji jak Pleroma, czyli własny serwer, który można uruchomić na Raspberry Pi.
Pozytywy
Jednak miało być o Mastodonie. Na początek dobre wiadomości. Coś jest i nawet działa. Nie jest to wielkie zaskoczenie, bo Diaspora* działała lata temu. Rejstracja konta na wybranej instancji trwała moment. W przeglądarce WWW jest OK i używalnie. Na mobilki są aplikacje. Jako klienta na Androida wybrałem Tusky, czyli jeden z popularniejszych klientów. Daje radę. I chyba nawet wygodniej mi się przegląda, czyli czyta, niż przez WWW.
Kolejny pozytywny aspekt – jest jakieś życie. Są ludzie, nawet dość regularnie piszą. I pisząc ludzi mam na myśli ludzi, nie konta, na których zapięty jest jakiś bot czyli automatyczny feed.
Są integracje. Na przykład WordPress ma wtyczki, które pozwalają zamieszczać informacje o nowych wpisach na Mastodon[3]. W przypadku Twittera korzystam do tego z 3rd party serwisu, a na niszowego Blablera sam dopisałem stosowny skrypt.
Sama platforma też generalnie działa i nie zauważyłem problemów z korzystaniem. Poza paroma zgrzytami, o których niżej.
Mastodon – negatywy
Niestety, porównując z Twitterem widać braki w funkcjonalnościach. Można followować[2] ludzi ale… już nie hashtagi. Follow użytkownika z innej instancji nie jest intuicyjny. Przynajmniej przez przeglądarkę. Ewentualnie są bugi. Objawia się to tym, że po wejściu na profil ofiary zawsze aktywny jest przycisk follow. Nawet, jeśli już obserwujemy osobę.
Wiele instancji daje się we znaki także gdy chcemy poznać obserwujących dane konto. Nie jest to proste ani dostępne w zasięgu jednego kliknięcia. Tusky w ogóle pokazuje chyba tylko followersów z naszej instancji i nie ma możliwości podejrzenia pozostałych. Przynajmniej ja nie znalazłem, a patrzyłem w ustawieniach, czy nie mam czegoś wyłączonego. Z kolei Mastodon przez WWW wyświetla komunikat:
Followers from other servers are not displayed. Browse more on the original profile
Czyli da się, choć wymaga dodatkowego kliknięcia. Porównując z rozwiązaniami scentralizowanymi – średnie.
Edycja posta w Diasporze jest wygodniejsza. Po przyzwyczajeniu i zapamiętaniu podstaw składni, Markdown jednak robi robotę, szczególnie na mobilkach, gdzie nie mamy wygodnego dostępu do klawisza ctrl. Mastodon tego nie ma – po prostu wpisuje się tekst. W 99% niekrytyczne.
Kolejna sprawa jest poważniejsza. Rozproszenie powoduje, że w przypadku zamieszczenia linka na przez popularne konto, następuje wiele pobrań przez wszystkie serwery obserwujących daną osobę, w celu wygenerowania podglądu. Taki DDoS przez pobieranie podglądu strony. Efekt można zobaczyć w wątku, z którego dowiedziałem się o sprawie. Było zgłoszone jako issue na GitHubie, ale nie zostało rozwiązane. I nie wiem czy zostanie, bo na szali jest wolność i autonomia działania instancji.
Największa wada w stosunku do „dużych” platform: mało ludzi, mało treści. O ile na Twitterze bez problemu jestem w stanie znaleźć kolejne kilka kont, których mógłbym chcieć followować, to na Mastodonie jest to wyzwanie. Może kwestia ilości kont, może kwestia architektury, a może jestem po prostu za krótko na tej platformie i z czasem się to zmieni? W każdym razie zauważam to i nie cieszy mnie.
Mastodon czyli wolność
No i na koniec coś co pewnie nie dotyczy całego Mastodona, ale akurat serwera, na którym mam konto i wydaje mi się śmiesznym ograniczeniem, jeśli chodzi o wolną platformę. Zasady serwera mówią, że nie wolno używać nienadzorowanych botów kopiujących z jednego miejsca na Mastodon i że nie wolno crosspostować z Twittera. Kierunkowo, bo w drugą stronę można. Zresztą jest to później wprost napisane:
Cross-posting from Mastodon to other platforms is fully permitted. Cross-posting into Mastodon from another platform is not permitted.
Nie przeszkadza mi to. Gdyby było inaczej mógłbym przecież założyć konto na swoim serwerze, albo postawić własny, nieprawdaż? Natomiast kojarzy się mocno z odpowiedzią Kalego na pytanie co to jest dobry uczynek? I rodzi pytania o kwestie wolności, możliwość działania na większą skalę i ogólnie przyszłość. Raczej przyszłość odległą, więc odpowiedzi nie wydają mi się w tej chwili zbyt istotne.
Podsumowanie
Mastodon przy odrobinie samozaparcia nadaje się do użytku. Koncepcja jest ciekawa, choć ma przed sobą kilka wyzwań. Zdecydowanie wymaga wygładzenia, jeśli chce móc konkurować z „dużymi” na masową skalę. Gdybym miał bawić się w przepowiadanie przyszłości, to jest spora szansa, że Mastodon wchłonie Diasporę. I bardzo mała, że w przeciągu najbliższych kilku lat stanie się zauważalną alternatywą dla Facebooka czy Twittera. Nawet, jeśli moda przetrwa.
Niemniej, u mnie zostanie. Prawdopodobnie właśnie pomału kanibalizując Diasporę.
[1] Jak wynika z wpisu, z kolei Szczeżuję do założenia Mastodona zainspirowałem ja, przy pomocy Diaspory. Rekurencja… [2] Przydałby się polski odpowiednik angielskiego follow. Niby jest śledzić, ale – podobnie jak obserwować – to pasywna obserwacja, z boku, bez aspektu podążania czyjąś ścieżką, popierania. [3] Jak widać na przykładzie tego wpisu, wtyczka nie zadziałała. Przyczyna nieznana i nawet nie wiem jak to debugować. UPDATE Po bliższym przyjrzeniu się opcjom, okazało się, że nie zaznaczyłem opcji „toot on mastodon” przy publikacji wpisu. O tyle bez sensu, że w opcjach wtyczki mam wybrane „autopost new posts”.
Za sprawą zbanowania Donalda Trumpa na Twitterze głośno zrobiło się w temacie wolności wypowiedzi w social media. Także odnośnie braku regulacji prawnych dotyczących social media i centralizacji usług. Zaczęły powstawać „wolne” alternatywy. Ponieważ zdarzyło mi się już tłumaczyć w paru miejscach moje stanowisko, pora na wpis.
Problem
W czym w ogóle problem? Przecież nigdy nie było tak, że każdy może skorzystać ze środków masowego przekazu. O treściach zamieszczanych w prasie decydował redaktor, podobnie w przypadku telewizji czy radio. Każdy mógł zadzwonić, ale na antenę nie dostawał się każdy. Dodatkowo obszar był uregulowany przez prawo prasowe. Choćby prawo do zamieszczenia sprostowania. I polemiki ze sprostowaniem. Nawet jeśli była np. w zakładzie pracy gablota na ogłoszenia, to miała ona właściciela. I mógł on nieodpowiadające mu treści po prostu usunąć. Albo zamknąć ją na kluczyk.
Sytuacja się zmieniła. Nie mamy już typowego broadcastingu, gdzie pojedyncza osoba rozgłasza treści, czyli jest nadawcą, a pozostali są odbiorcami. Obecny model zdemokratyzował bycie nadawcą. Każdy może publikować treści, które są dostępne dla wszystkich. Ale nie to jest najważniejszą zmianą. Już wcześniej każdy mógł uruchomić swoje radio, czasopismo czy postawić własną gablotę z ogłoszeniami. Oczywiście o ile miał odpowiednie środki i kompetencje. Pieniądze i znajomość prawa, powiedzmy.
Najważniejsze zmianą jest coś innego. W sumie nie zmianą, a zmianami. Po pierwsze, social media sprawiły, że publikacja treści dla wszystkich nie wymaga istotnych nakładów ze strony nadawcy. Nie są potrzebne ani specjalne środki, ani kompetencje, by zacząć przekaz do wszystkich w kraju i na świecie. O ile będą chętni, by nas słuchać.
Prawa człowieka
Po drugie i najważniejsze, ten sposób komunikacji stał się powszechny i dominujący. Odebranie komuś możliwości publikowania poglądów w ten sposób jest pewnego rodzaju wykluczeniem społecznym. Trochę tak, jakby kiedyś zabronić komuś rozmawiać w szkole czy zakładzie pracy. Dotyczy to zarówno w życia prywatnego, jak i – w niektórych przypadkach – zawodowego. W przypadku niektórych istotna część życia zawodowego toczy się na Linkedin czy GitHub[1] . Wyobrażacie sobie rekrutera pracującego w branży IT z wykluczonym korzystaniem z Linkedin? Ja nie.
Dlatego coraz częściej pojawiają się głosy, że prawo do internetu to podstawowe prawo człowieka. W badaniu w roku 2010 77% ankietowanych spośród 27 tys. osób z 26 krajów Europy określiło, dostęp do internetu jako podstawowe prawo człowieka[2]. Wydaje mi się, że można w tym momencie utożsamić internet z social media.
Centralizacja i struktura serwisów social media
Oba przytoczone wyżej serwisy są centralne. Podobnie jak Twitter czy Facebook. W tym momencie pojawia się pytanie o wolność i regulacje prawne. W kontekście wolności słowa i prawa człowieka. Aby dokładniej zobaczyć w czym problem, trzeba przeanalizować strukturę władzy w serwisach social media. Typowo wygląda ona następująco:
Właściciel serwisu – ten, który ma środki. Pieniądze, prawa do domeny, przetwarzania danych użytkowników itp.
Dostawcy infrastruktury – podmioty zapewniające łączność i hosting. Firmy zewnętrzne, ale w większości przypadków niezbędne dla funkcjonowania.
Administrator serwisu – osoba z wiedzą techniczną, umiejąca utrzymać serwis w działaniu. Zarządzanie infrastrukturą, konfiguracja oprogramowania. Może być po prostu pracownikiem na usługach właściciela.
Moderatorzy serwisu – osoby mogące usuwać treści lub użytkowników. Niekoniecznie w kontekście całego serwisu, mogą zarządzać wydzieloną częścią (np. grupą na FB). Mogą być pracownikami na usługach właściciela lub rekrutować się z użytkowników.
Użytkownicy – osoby korzystające z serwisu. Uczestnicy komunikacji. Nadawcy i odbiorcy treści.
Oczywiście funkcje mogą się łączyć. Istotny jest tu fakt, że każda instancja wyższa ma środki techniczne, by ograniczać w dowolny sposób wszystkie instancje niższe. Także eliminując zupełnie ich dostęp do serwisu.
Nawiasem, zagadnienie jest szersze. Temat nie dotyczy tylko typowych social media i tylko o ograniczanie dostępu. Gdy Google, Agora czy Wirtualna Polska mówi, że zamyka serwis to użytkownicy nie mają nic do powiedzenia. Nie muszą nawet dostać możliwości pobrania pełnych treści w formacie zdatnym do łatwego przetworzenia maszynowo. Podobnie z blokowaniem dostępu do serwisów, w szczególności do publikacji treści.
Centralizacja
Nie jest to temat nowy, dominująca rola gigantów social media została dostrzeżona już dawno. Pojawiły się rozwiązania alternatywne, oparte o fediwersum. Czyli osobne, niezależne serwisy, ale dające możliwość interakcji między użytkownikami różnych instancji.
Na pierwszy rzut oka fediwersum wydaje się to rozwiązaniem problemu centralizacji. Ale czy jest nim faktycznie? Uważam, że nie. Gwarancja wolności w tym przypadku opiera się na tym, że użytkownik może pójść na inną instancję. Albo, w skrajnym przypadku, uruchomić własną.
Niestety, uruchomienie własnej instancji leży poza kompetencjami większości użytkowników. Uruchomienie to kompetencje administratora, a istniejące rozwiązania wymagają specjalistycznej wiedzy. Nie są może trudne dla ludzi z IT, ale świat nie składa się ani wyłącznie, ani nawet w większości z ludzi z IT.
Co gorsza, nawet uruchomienie własnej instancji nie gwarantuje, że ludzie z innych będą mieli dostęp do naszych treści. Wymiana danych między instancjami jest bowiem opcjonalna, dobrowolna i może zostać zablokowana. Na wielu poziomach, od konfiguracji instancji, przez filtrowanie pakietów sieciowych. Oczywiście takie rozwiązanie zmniejsza centralizację, ale nie eliminuje źródła problemu.
Rozwiązanie
O rozwiązaniu problemu centralizacji możemy mówić, gdy dowolnych dwóch użytkowników, którzy wyrażą taką wolę, będzie się mogło komunikować ze sobą. Niezależnie od decyzji innych osób i przynależności do serwerów. Fediwersum takiej gwarancji niestety nie daje[3]. I nie znam rozwiązania, które coś takiego oferuje.
Technicznie widziałbym to jako oddanie pełnej decyzyjności o odbieranych informacjach w ręce użytkowników końcowych. Czyli protokół pozwalający na wymianę informacji ze wszystkimi, nie dopuszczający cenzurowania. I prosta aplikacja, zastępująca serwis, używalna dla zwykłych użytkowników, pozwalająca na korzystanie (subskrybcję tematów, tagów, użytkowników, nadawanie, odbieranie wiadomości) przy pomocy tego protokołu. Z możliwością filtrowania użytkowników, tagów, tematów zarządzaną na poziomie użytkownika.
Wydaje mi się, że blisko tego modelu – pomijając aspekt centralnych serwerów – byliśmy w czasach NNTP. Użytkownik miał swój czytnik, swoje subskrybcje i filtry. Pobierał co chciał, odsiewał co chciał. Korzystanie z czytnika nie było wiele trudniejsze, niż obsługa email. Oczywiście wtedy obsługa email nie była powszechna, a i UX aplikacji był inny.
Gdyby dołożyć do tego „niecenzurowalny”, rozproszony protokół wymiany danych, mielibyśmy coś, co wydaje mi się rozwiązaniem. Nie znam szczegółów rozwiązania, ale wydaje mi się, że IPFS miałby szanse spełnić te wymagania. Tym bardziej, że zdobywa popularność – wchodzi do przeglądarek, na przykład jest już oficjalnie w Brave.
[1] Tak, uważam GH za pewnego rodzaju social media. Nie typowe socjalne, bardziej techniczne, dla wąskiej grupy, ze specyficznym elementem socjalnym, ale nadal twór tego typu. Na zasadzie: zwykli ludzie pokazują fotki i komentują je, programiści pokazują kod, wysyłają pull requesty. Nie jest to oczywiście dokładna analogia. [2] 50% odpowiedzi tak, kolejne 27% raczej tak. [3] Widzę, że PeerTube jest częścią fediwersum. I wydaje mi się odporne na cenzurowanie. Może więc być tak, że problemem są implementacje. W każdym razie pisząc o fediwersum mam tu na myśli implementacje w stylu Diaspora, Mastodon, StatusNet.