Jakiś czas temu Konwenty Południowe poruszyły temat braku protokołów TLS/SSL na witrynach konwentów. Chociaż artykuł miał clickbaitowy tytuł i ton, sugerujący wielki atak, nic tak naprawdę się nie stało. Jeszcze. Używanie szyfrowanego połączenia między klientem a serwerem to jednak kropla w morzu zapotrzebowań zabezpieczeń przed atakami hakerskimi.
Szyfrowane połączenia są ważne w momencie, gdy przesyłamy dane wrażliwe. O ile raczej nic się nikomu nie stanie, gdy ktoś odkryje nasze imię i nazwisko, tak zdecydowanie gorzej jest w przypadku haseł, numerów PESEL czy telefonu. Z takim zestawem informacji można mocno komuś zaszkodzić, ale z punktu widzenia hackera obserwowanie strony wydarzenia na kilkaset osób jest mało opłacalne. Większe wydarzenie może oznaczać jednak większe zainteresowanie ze strony hackerów.
Oczywiście, nie mówię, że to się nie może zdarzyć, ale prędzej przechwycenie danych nastąpi w publicznej i ogólnodostępnej sieci (np. darmowe WiFi na dworcach), niż podczas korzystania z internetu w domu czy pracy. Trzeba pamiętać też, że strona używająca protokołu HTTPS do inicjacji bezpiecznego połączenia, wcale nie musi być taka bezpieczna. Certyfikat takiego połączenia może być od początku złośliwy.
Kolejnym problemem jest przechowywanie danych. Zabezpieczenie ich przed kradzieżą to nie lada wyzwanie dla informatyka. O ile w bazach hasła zwykle przechowywane są w formie zaszyfrowanej, nie oznacza to, że to w pełni bezpieczna forma. Ważne jest, aby takie dane zostały przesłane do serwera poprzez wspomniany wcześniej protokół TLS.
Samo szyfrowanie w bazie danych to też skomplikowana sprawa. Algorytmy kryptograficzne są bezpieczne tak długo, jak ktoś nie znajdzie w nich luki. Taka metoda doczekuje się wtedy kolejnej wersji, która problem rozwiązuje. Wymaga to jednak pracy ze strony programisty – aby uaktualnić skrypt na stronie. Niektóre konwenty korzystają z rozwiązań, które nie są rozwijane od ładnych paru lat. Stawiam kokosy przeciwko orzechom, że użyte w nich szyfry kryptograficzne są już podatne na ataki.
Pozostaje kwestia innych wrażliwych danych, które przetrzymywane są w bazie. Możemy oczywiście je też zaszyfrować – ale najczęściej w takiej sytuacji liczy się bezpieczeństwo serwera. Konwenty bardzo często wybierają najtańsze opcje hostingowe, nie zwracając uwagi na to w ogóle, jakie bezpieczeństwo oferuje nam dostawca. Ufamy mu bezgranicznie, bo przecież sprzedaje swoją usługę, więc wie, co robi. Nie oznacza to, że mu zależy. Można oczywiście postawić swój serwer – jeśli tylko ma się na to środki. Będzie to rozwiązanie droższe, ale pewniejsze – bo sam nadworny informatyk będzie mógł aktualizować wszystkie luki, pod warunkiem, że będzie miał na to czas (i posiadał wiedzę).
Pojawia się pytanie – czy warto przechowywać dane użytkownika na swoim serwerze, korzystając ze swoich metod? Jeśli nasz informatyk ma czas i będzie aktualizował rozwiązania bezpieczeństwa – problem nie istnieje. Ale zawsze następuje zmiana warty, w końcu każdemu z nas kiedyś skończy się energia na wolontariat. Czy nie lepiej w takim wypadku spróbować czegoś innego?
Federacja tożsamości od Google może być tym, czego potrzebuje konwent mający problem z czasem informatyka. Korzystając ze swojego konta Google, możemy zarejestrować/zalogować się na stronie aplikacji. Dużą zaletą tego rozwiązania jest nie przetrzymywanie danych konta na serwerze aplikacji. Tworzone jest tylko wirtualne konto, które identyfikuje się z Google na podstawie atrybutów wysłanych w tokenie. Co ważne – wśród informacji o naszej tożsamości nie ma żadnych danych wrażliwych, nawet hasła. Oczywiście, Google to nie jedyny dostawca tożsamości. Rozwiązania tego typu oferuje również Facebook, Twitter, Twitch czy nawet banki. Wbrew powtarzanym przez niektórych opiniom, jest to bardzo bezpieczne rozwiązanie.
Ale i tak mamy tu kolejny problem. Jeśli ktoś zdobędzie dostęp do naszego konta Google, uzyska dostęp do wszystkich serwisów, do których je podłączyliśmy. Można oczywiście włączyć weryfikację dwuetapową poprzez SMSa, ale ostatnie informacje o wyrobieniu duplikatu karty u operatora przez osobą trzecią podważają pewność takiego rozwiązania. Są rzecz jasna inne formy weryfikacji dwuetapowej (np. Google Authenticator) i, w miarę możliwości, polecam korzystanie z nich.
Niestety, wiele stron konwentów (i nie tylko) nie oferuje praktycznie żadnych zabezpieczeń dodatkowych, które uratują nas w razie wycieku naszego hasła. W ramach wygody wielu z nas korzysta z jednego hasła do wielu aplikacji – w końcu ile silnych haseł jesteśmy w stanie zapamiętać? Dobrym rozwiązaniem jest korzystanie z menedżera haseł, niekoniecznie tego wbudowanego w naszą przeglądarkę. Przykładem takiej aplikacji jest na przykład KeePass, który przechowuje w formie zaszyfrowanej hasła na naszym komputerze, ale przed dostępem wymaga podania osobnego hasła. Oczywiście, musimy sami zadbać o odpowiednią siłę hasła do naszego manadżera haseł.
Jeśli jest jakaś stała w bezpieczeństwie informatycznym, to fakt, że najsłabszym ogniwem zawsze jest człowiek. Konwent może dołożyć wszelkich starań, żeby dane użytkownika były bezpieczne, ale nic to nie da, jeśli jego hasło to Password123. Dlatego budowanie świadomości o bezpieczeństwie teleinformatycznym jest ważne. Ale dla mnie ważniejsze jest pytanie – czy w dobie RODO konwenty naprawdę potrzebują jakichkolwiek danych o zwykłym uczestniku?
Przy tylu miejscach, w których może dojść do wycieku danych, dla małej imprezy to gra nie warta świeczki. RODO jest bezwzględne i niedopełnienie swoich obowiązków może sporo kosztować organizatorów. Większe imprezy też nie mają łatwo, bo zrobienie zabezpieczeń IT dla konwentu, to nie jest praca magisterska, nie ma tu miejsca na pomyłki. Osobiście znam niewiele osób, które poświęciłyby swój czas i zasugerowałyby najlepsze rozwiązania dla danej imprezy. O płaceniu nie mówmy, bo płaca specjalisty do spraw bezpieczeństwa IT wykracza poza budżet niejednej imprezy.
Dane osobowe to bardzo drażliwy temat. Zwolennicy ich zbierania sugerują, że dzięki nim można bez problemu wydać duplikat wejściówki czy rozwiązać inne problemy nieuważnego uczestnika. To prawda, ale jak wspomniałem wyżej, ilość niebezpieczeństw czyhających na bazy danych uczestników w internecie, jest ogromna. Według mnie, najbezpieczniej jest zwyczajnie danych osobowych nie zbierać, a uczestnik imprezy na swój identyfikator powinien zwyczajnie uważać.