Twitter wyłącza 2FA

Przepraszam za clickbaitowy tytuł, ale tak podobno zostały odebrane ostatnie działania i wiadomości wysyłane przez ten serwis. Zatem, gwoli ścisłości nie 2FA, tylko jedną z metod 2FA (SMS) i nie wyłącza, a udostępnia jedynie w płatnej wersji usługi. Nadal można mieć na Twitterze 2FA, za darmo, w dodatku w teoretycznie bezpieczniejszej wersji.

Wiadomość od Twittera w sprawie SMS Źródło: https://twitter.com/jsrailton/status/1626791204238008320

Motywacja jest oczywista. Chodzi o pieniądze. Wszyscy się przyzwyczailiśmy, że SMSy są darmowe, w pakiecie lub abonamencie. Bo taka jest rzeczywistość, przynajmniej w Polsce i dla SMSów wysyłanych w kraju. Tyle, że sytuacja z puntku widzenia serwisu internetowego wygląda nieco inaczej – korzystają z zewnętrznych dostawców, wysyłają do różnych krajów. To jest usługa, która kosztuje i to zapewne niemało. Czyli SMSy to taki rodzaj 2FA, gdzie całość kosztu ponosi serwis. No chyba, że przerzuci ten koszt na użytkownika, co Twitter właśnie zrobił.

Przy okazji, SMSy to jeden z najsłabszych rodzajów 2FA. Dla przeciętnego użytkownika Twittera być może nie ma to praktycznego znaczenia[1], ale istnieją ataki pozwalające na obejście tej metody komunikacji. Jak widać były w praktyce stosowane, także do przejmowania kont na Twitterze. Co gorsza, ofiara, czyli właściciel konta z takim 2FA praktycznie nie ma wpływu na skuteczność tych ataków. Atak odbywa się bowiem na dostawcę sieci komórkowej, a w zasadzie na jego pracowników obsługi klienta.

Dygresja: jeśli korzystamy z serwisu na telefonie i odbieramy SMS służące do 2FA na tym samym telefonie, to czy to jest jeszcze drugi składnik zaczyna być mocno dyskusyjne. Zależy od zagrożenia, przed którym chcemy się bronić. Dla kradzieży hasła czy sesji np. przez XSS wystarczy, dla malware na telefonie czy kradzieży telefonu – niekoniecznie. Dotyczy to także innych metod 2FA, jak email czy TOTP w Google Authenicator[2] czy aplikacji.

Niezależnie od motywacji, zapewne przypadkiem, Twitter został pionierem rewolucji w security na miarę walki Orange ze spamem przez zablokowanie wysyłki maili na porcie 25. Jest to pierwszy duży serwis, który odsyła przestarzałe 2FA via SMS tam, gdzie jego miejsce. Tj. do fanaberii typu papierowa faktura w usługach masowych. Tu od dawna mamy mniej lub bardziej zawoalowane opłaty za wystawianie papierowych faktur. Zwykle w formie „będzie 5 zł taniej, warunkiem skorzystania z promocji jest wyrażenie zgody na faktury elektroniczne”. I jakoś nikt z tym nie ma problemu. Chociaż faktury elektroniczne są także tańsze dla firm. Ale lepsze, bo nie marnujemy papieru i środków na jego transport.

Jeśli ktoś chce nadal korzystać za darmo z 2FA dla konta na Twitterze, to nadal ma dostępne takie opcje:

Opcje 2FA na Twitterze. Źródło: https://twitter.com/mkusiciel/status/1626851994097922048

Według mnie marginalizacja 2FA via SMS to dobra zmiana i będę kibicował innym serwisom, które się zdecydują na jej wprowadzenie. O wadach i zaletach poszczególnych metod 2FA może napiszę innym razem.

[1] Przykro mi, nikomu nie zależy na przejęciu naszych kont. A przynajmniej nie jest to warte ryzyka i/lub kilkuset złotych.
[2] Upraszczam, nie tylko Google Authenticator to oferuje. Tak naprawdę to trywialny algorytm, ale ta implementacja jest najbardziej znana i chyba najpopularniejsza.

Publiczne Wi-Fi a bezpieczeństwo

Wczoraj ukazał się artykuł o tym, czy korzystanie z publicznego Wi-Fi jest bezpieczne. Uważam, że prezentowane tam podejście jest dość optymistyczne. Nie uważam obcych sieci za tak bezpiecznie, jak pisze autor. Wszystko zależy od tego, czego się obawiamy. I naszego poziomu paranoi.

Na pewno podłączanie do sieci Wi-Fi, jeśli zakładamy złe zamiary jej właściciela lub innych użytkowników jest bezpieczniejsze, niż podłączanie kablem ethernetowym. Ot, nikt nie poda wysokiego napięcia na kablu i nie spali nam urządzenia. No ale żarty na bok.

Publiczne Wi-Fi – zagrożenia

Podłączając się do cudzej lub publicznej sieci ujawniamy informacje o swoim urządzeniu i systemie. Np. syngatury urządzenia typu adres MAC czy hostname. W pewnych przypadkach dane te mogą zostać wykorzystane do… powiedzmy przypisania nam pewnych działań. Ale to bardziej naruszenie prywatności niż realny atak. Pójdźmy dalej.

Podłączając się do sieci eksponujemy nasze urządzenie na bezpośrednie połączenia. OK, jeśli ktoś ma firewall lub nie udostępnia żadnych usług innym komputerom w sieci lokalnej, to problemu nie ma. Ale już udostępnienie zasobu chronionego prostym hasłem z laptopa w sieci domowej, gdzie bezpośredni dostęp miały tylko nasze urządzenia może okazać się zgubne. W naszej sieci przed atakami z internetu mógł chronić router (NAT).

Nie taki HTTPS wspaniały

Wspomniany w artykule HSTS ma dwie wady. Po pierwsze, adopcja. Zwyczajnie nie wszystkie strony z niego korzystają. Żeby daleko nie szukać, tamten artykuł zamieszczony jest na stronie bez HSTS. I pewnie ktoś przytomnie zauważy, że przecież to tylko blog, a nie bank. To polecam samodzielne sprawdzenie, czy, ew. które polskie banki korzystają z HSTS na stronach. O HSTS z preload litościwie nie wspominam.

Po drugie, jest to mechanizm TOFU. Tzn. nie zapewnia bezpieczeństwa przy pierwszym połączeniu. Owszem, przeglądarka w kolejnych połączeniach do strony, przez zwykle długi okres ważności, będzie już korzystać z HTTPS. Ale jeśli jest to nowa strona lub otwierana w nowej przeglądarce to HSTS nic nie daje.

Dodatkowo autor wspomina o powszechnych przekierowaniach HTTP -> HTTPS. Tylko niestety taki mechanizm nie zapewnia bezpieczeństwa. OK, może je podnosić w szczególnym przypadku, jeśli jest stosowany łącznie z HSTS. Bez tego raczej zapewnia złudzenie bezpieczeństwa. Bowiem jeśli pierwszy request jest wykonywany po HTTP, to nadal DNS spoofing jest groźny. Atakujący może dowolnie rozwiązać nazwę domeny do której próbujemy się połączyć. Np. na swój serwer. I tam wykonać przekierowanie HTTP. Redirect (301) może być na cokolwiek. Także na domenę z poprawnym HTTPS. Tyle, że niekoniecznie tę, na którą chcieliśmy się połączyć. Tylko np. na domenę homograficzną, albo domenę o zbliżonej nazwie. Ot, choćby wchodząc na http://mojbank.pl możemy skończyć na https://mojbark.pl, o wyglądzie identycznym jak https://mojbank.pl. I z poprawnym certyfikatem HTTPS i „kłódeczką”.

No i ostatecznie nawet połączenie HTTPS z poprawnym hostem nie gwarantuje jeszcze, że jest w pełni bezpiecznie. W niektórych przypadkach, na które użytkownik nie ma wpływu, nadal możliwe mogą ataki na HTTPS. OK, w przeciwieństwie do DNS spoofingu są trudniejsze do wykonania.

Jak korzystać bezpieczniej z publicznych Wi-Fi?

Czy to znaczy, że zupełnie nie zgadzam się z autorem? Niekoniecznie. Zgadzam się, że jest o wiele bezpieczniej, niż kiedyś. Generalnie jeśli ktoś naprawdę musi skorzystać z Wi-Fi i miałbym dać tylko jedną radę to byłoby to: włącz DoH w przeglądarce i wpisuj adresy w pasku adresu przeglądarki „z palca”, korzystając z podpowiedzi. No wiem, to w zasadzie dwie rady. Ale przyjmijmy, że jedna, tylko złożona.

Czemu tak? DoH zapewni nam odporność na DNS spoofing, a dodatkowo da bonus w postaci podwyższenia prywatności. Potencjalny podsłuchujący nie dostanie adresów odwiedzanych stron „na tacy” w postaci nieszyfrowanych zapytań DNS. W części przypadków w ogóle nie będzie w stanie ustalić z jakim serwisem się łączymy.

Wpisywanie domen w pasku adresu, z wykorzystaniem podpowiedzi uchroni przed kliknięciem w podobną domenę i zwiększy szansę na wykorzystanie protokołu HTTPS już od pierwszego requestu.

Hashcat na M1

Jakiś czas temu pisałem o przesiadce na M1. Musiałem użyć hashcata i… przypomniało mi się, że nowe M1 ma poważną zaletę, w postaci szybkości. Żeby zobaczyć faktyczną różnicę, pozwoliłem sobie na nanobenchmark.

Nawiązując do starego wpisu o przyspieszaniu hashcata, sprawdziłem md5crypt:

* Hash-Mode 500 (md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)) [Iterations: 1000]
Speed.#1.........:  1902.0 kH/s (53.57ms) @ Accel:512 Loops:500 Thr:32 Vec:1

Drobne cztery razy szybciej w stosunku do starego laptopa. Nie powala, ale wzrost przyjemny. Sprawdźmy więc inne typy hashy:

METAL API (Metal 263.8)
=======================
* Device #1: Apple M1 Pro, 10880/21845 MB, 16MCU

OpenCL API (OpenCL 1.2 (Apr 19 2022 18:44:44)) - Platform #1 [Apple]
====================================================================
* Device #2: Apple M1 Pro, skipped

Benchmark relevant options:
===========================
* --optimized-kernel-enable

-------------------
* Hash-Mode 0 (MD5)
-------------------

Speed.#1.........:  5713.7 MH/s (92.80ms) @ Accel:1024 Loops:1024 Thr:32 Vec:1

----------------------
* Hash-Mode 100 (SHA1)
----------------------

Speed.#1.........:  2031.9 MH/s (64.99ms) @ Accel:256 Loops:1024 Thr:32 Vec:1

---------------------------
* Hash-Mode 1400 (SHA2-256)
---------------------------

Speed.#1.........:   598.6 MH/s (54.90ms) @ Accel:64 Loops:512 Thr:64 Vec:1

Jakieś dwanaście razy szybciej w przypadku MD5 w stosunku do poprzedniego laptopa. Albo połowa wydajności Tesla 4. Miło. Jako podręczna maszynka w zupełności wystarczające.

Wszystkie powyższe wyniki benchmarków robione dla M1 z 10 core CPU i hashcata w wersji v6.2.5-516-g372d3a127.

Tym, którzy nie mają dostępu do M1, zostają inne sposoby, np. poproszenie Google o użyczenie mocy obliczeniowej.