Nowa reCAPTCHA

Pojawiło się doniesienie o wprowadzeniu przez Google nowej wersji reCAPTCHA. Nazwa jest piękna Google Cloud Fraud Defense. Od razu wiadomo, jak opakowana została zmiana, w imię której będziemy poświęcać wolność. Walka z nadużyciami, bezpieczeństwo. W artykule jest security, safety, trust i fraud. Oczywiście pojawia się też AI.

Trochę miałem do czynienia z rozwiązaniami do detekcji botów, wydaje mi się, że widzę, w czym rzecz. Nowatorstwo rozwiązania nie jest w QR-code. Nie jest w konieczności użycia drugiego urządzenia do odczytania danych z pierwszego. To wszystko można oprogramować i zasymulować i zrobić na tym samym urządzeniu, automatycznie.

Prawdziwa natura nowego rozwiązania jest wg mnie widoczna w niepozornym fragmencie: By correlating telemetry across the entire lifecycle, our unified trust model identifies complex, multi-stage fraud campaigns that disconnected point solutions miss. This holistic view has demonstrated […] Wytłuszczenia moje.

Zmierzamy do tego, że poprawne rozwiązanie CAPTCHA, tj. bycie słusznie uznanym za człowieka, będzie opierało się na tym, że przynajmniej na jednym z urządzeń – o ile nie na obu – trzeba będzie wyrazić zgodę na telemetrię. Czyli pozwolić dostawcy – tu: Google – na pobieranie masy danych z urządzenia i o urządzeniu. O położeniu (geolokalizacj), o IP, o stanie baterii, zainstalowanych kodekach, fontach, o tym, jak i kiedy się porusza (akcelerometry). Wreszcie metadane o tym, które urządzenia były powiązane z którymi. I nie, nie na chwilę, tylko holistycznie przez cały cykl życia (cokolwiek ma to znaczyć).

A jeśli nie wyrazimy zgody? No cóż, w najlepszym wypadku stracimy więcej czasu na częstsze skanowanie lub rozwiązywanie innych form CAPTCHA. W najgorszym? Zostaniemy uznani za boty i pozbawieni dostępu do usług.

Czy będzie to skuteczne? Cóż, na początku pewnie tak. Czy da się obejść? Pewnie tak, ale wątpię, by obejście zyskało masową popularność. Ale masa danych, łatwych do skorelowania i niosących wiele informacji nie wprost trafi do dostawcy (tu: Google).

Dlatego mam szczerą nadzieję, że rozwiązanie spotka się z bojkotem użytkowników. Zarówno tych, którzy mieliby rozwiązywać CAPTCHA, jak i tych, którzy wybierają rozwiązanie, które wykorzystują. Zawsze zamiast rozwiązywać CAPTCHA można zrezygnować z dostępu/zakupu i zamiast tego zgłosić problem z dostępem do danych na stronie.

UPDATE: Nie padło to w pierwotnej wersji wpisu, ale oczywiście chodzi o umacnianie monopolu Google (ew. duopolu, bo jeszcze Apple). Weryfikacja na systemie Android wymaga telefonu z Google Play.

WordPress antyspam

Po raz kolejny musiałem zająć się problemem spamu w komentarzach na blogu. Przesiadka na hCaptcha pomogła na dłuższy czas, ale pod koniec lipca zabezpieczenie przestało działać[1]. Chwilę po tym, jak pojawiły się pierwsze komentarze, które przeszły hCaptcha, ruszyła lawina. Może raczej lawinka, bo 1-2 spamy dziennie to niewiele. Tak czy inaczej, wygląda, albo że spamerzy, że spamerzy szybko się uczą, albo mają bazę, który blog jaką ma captchę[2], albo hCaptcha istotnie się pogorszyła, albo ilość prób wzrosła na tyle, że coś się zaczęło przebijać[3]. A może wręcz znaleziono sposób na jej omijanie? Tematyka i języki różne, bez ładu i składu. Jedyne co pamiętam, to że zaczęło się od Azji, konkretnie pierwsze spamy wysłane w tej serii do mojego WordPressa były po… wietnamsku.

Garść statystyk

Zamieściłem statystyki poprzednio, więc zrobię to i teraz. Pomiędzy 20.06.2021 a 23.07.2022 zupełny brak spamu. W okresie od 23.07.2022 do 08.11.2022 73 sztuki. W 108 dni średnio 0,67 spamu na dobę. OK, to nie 1-2 dziennie, ale nadal sporo.

CAPTCHA

Moją pierwszą reakcją było zwiększenie trudności w panelu hCaptcha. Z najniższej na średnią. Niestety, nie zauważyłem spodziewanego efektu. Rozważam jeszcze powrót do reCAPTCHA. Jeśli spamerzy faktycznie mają bazę z typem zabezpieczeń na danym blogu, to taka zmiana może nieco popsuć szyki. Niemniej, skoro kiedyś nie dawała rady, to czemu teraz miałaby pomóc? Inna opcja to zwiększenie trudności do maksimum. Tylko to utrudni też życie zwykłym czytelnikom, a tego nie chcę.

Blokowanie IP

Zauważyłem, że IP z których zamieszczany jest spam w komentarzach, są raczej wątpliwej reputacji. Zatem kolejnym krokiem, połączonym z migracją hostingu, było zablokowanie na iptables z wykorzystaniem ipset tych IP, które są listowane w wybranych listach projektu firehol. Nieco pomogło na spam, zdecydowanie nie całkowicie. Ale i tak gorąco polecam to rozwiązanie, bo ilość ruchu z tych IP jest całkiem spora[4]. Niczego pozytywnego ze strony botnetów, open proxy itp. wynalazków się nie spodziewam, więc czemu nie zablokować?

Wtyczki

Skoro wycinanie IP nie pomogło, to pora sięgnąć po broń ostateczną. Tu jest WordPress, tu się instaluje wtyczki! Wtyczek obiecujących rozwiązanie spamu w komentarzach jest dla WordPressa sporo.

Akismet

Ponieważ kolejny raz polecono Akismet w komentarzach wpisu, więc zacząłem od niego. Pamiętam, że kiedyś już się przymierzałem do tego rozwiązania i odrzuciłem je. Po pierwsze, wymaga założenia osobnego konta. To mógł być wtedy wystarczający powód do odrzucenia. Po drugie, Akismet jest płatny. Tzn. teoretycznie jest pay what you want, ale nie da się zapłacić $0, jeśli ma się jakiekolwiek reklamy na blogu. Zaś what you want to minimum $1 miesięcznie. Tak się składa, że na niektórych stronach mam reklamy. Przynoszą grosze, ale są, a zakładanie konta, podawanie karty kredytowej to trochę za dużo, żeby przetestować rozwiązanie. Poza tym, skończyło by się tak, że wyświetlam reklamy, aby zapłacić za wtyczkę blokującą spam. Za którą muszę płacić, bo mam reklamy.

Antispam Bee

Kolejna popularna wtyczka antyspamowa dla WordPressa to Antispam Bee. Jest darmowa, wygląda sensownie, ma sporo więc dostała szansę. Trochę zdziwiło mnie działanie. Po włączeniu chciałem przetestować, wysłałem komentarz i… bez zmian, trafił od razu do moderacji, bez żadnych oznaczeń. Aż zwątpiłem, czy wtyczka działa przed moderacją, czy po. Jednak pierwszy spam pokazał, że wtyczka działa. Przed moderacją, a wykryty spam już nie niepokoi moderatora. Gdybym nie włączył powiadomień mailem, to bym nie zauważył. Znaczy pełen automat. Potrzeba trochę czasu, by ocenić skuteczność, ale wygląda obiecująco.

[1] Być może ma to jakiś związek ze zmianą hostingu, która koreluje czasowo. Tylko to mogłoby tłumaczyć jedynie znalezienie bloga, nie działanie zabezpieczeń.
[2] Tylko wtedy szkoda, że chyba nie ma w tej bazie pola „ręczna moderacja komentarzy, odpuść sobie”.
[3] Już po napisaniu tego wpisu zrobiłem szybką analizę i faktycznie, z ruchu wytypowanego jako boty zamieszczające spam, 95% dostaje HTTP status code 400. Pozostałe 5% dostaje 200.
[4] Aktualnie korzystam z dwóch list: stopforumspam oraz blocklist.net.ua. Kompromis między ilością IP (ok. 300 tys.), a efektem. Może się zmieniać, bo dodanie kolejnej listy jest trywialne.

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?