Paweł Goleń, blog

Certyfikat klienta

Część systemów bankowości internetowej wymagają uwierzytelnienia klienta już na poziomie połączenia SSL. Rozwiązanie to jest obecnie raczej rzadko spotykane w przypadku bankowości detalicznych. Choć skutecznie ogranicza powierzchnię ataku, to dla przeciętnego użytkownika jego stosowanie jest niewygodne. Głównie dlatego, że trzeba go mieć, by uzyskać dostęp do systemu. Wymaganie certyfikatu po stronie klienta jest implementowane w części systemów adresowanych do klientów korporacyjnych.

Certyfikat klienta, jeśli jest wykorzystywany, powinien być osadzony w urządzeniu kryptograficznym (karta kryptograficzna, token). Certyfikat i klucz prywatny zapisany w pliku może zostać wykradziony przez stosowny malware.

Unikalna domena

Serwis powinien być oddzielony od innych stron banku. Wynika to z implementowanej w przeglądarkach Same-origin policy. Podejście, gdzie przykładowo http://bank.domena.pl wskazuje na serwis informacyjny, a https://bank.domena.pl na serwis transakcyjny, jest złe. Sama domena powinna się w sposób jednoznaczny kojarzyć z bankiem. Niekiedy działy marketingu "wykazują się" kreatywnością, wymyślając chwytliwe nazwy, które w żaden sposób nie kojarzą się z bankiem utrzymującym/oferującym usługę. W pewnym zakresie zwiększa to szanse na powodzenie phishingu, po prostu atakujący wymyśla nową, chwytliwą nazwę, a użytkownik przyzwyczajony do dziwnych nazw, nie zastanawia się nad jej znaczeniem i faktem, że przecież do tej pory zwykle logował się na inną stronę.

Certyfikat serwera i szyfrowana komunikacja

To, że system powinien umożliwiać dostęp wyłącznie z wykorzystaniem protokołu HTTPS z wykorzystaniem SSLv3 lub TLSv1 i mocnych szyfrów, jest już chyba oczywiste. Do tego oczywiście certyfikat serwera, dobrze jeśli jest to certyfikat EV. Obecnie praktycznie każda przeglądarka dodatkowo "podkreśla" fakt przedstawienia się serwera przy pomocy certyfikatu EV, dzięki czemu (przynajmniej w teorii) weryfikacja takiego certyfikatu przez klienta (człowieka), jest łatwiejsza.

Uwierzytelnienie

Na temat uwierzytelnienia już kiedyś pisałem: O bezpieczeństwie bankowości elektronicznej - uwierzytelnienie. Dobrze, jeśli uwierzytelnienie jest dwuskładnikowe.

Najsłabszą metodą uwierzytelnienia (w sensie - najłatwiejszą do zaatakowania) jest hasło. Również wykorzystanie hasła maskowanego nie powoduje znacznej poprawy sytuacji, patrz: Hasła maskowane są ZŁE!. Zarówno w przypadku "pełnych" haseł, jak i haseł maskowanych wykorzystywane są często klawiatury wirtualne. W praktyce obecnie "wartość dodana" wnoszona przez to rozwiązanie jest pomijalna.

Uwierzytelnienie przy pomocy podpisu cyfrowego ma sens, jeśli klucz prywatny umieszczony jest w urządzeniu kryptograficznym (token, karta kryptograficzna). W przeciwnym wypadku może on (wraz z "hasłem") zostać wykradziony przez malware.

Przykładem uwierzytelnienia dwuskładnikowego może być połączenie hasła maskowanego z kodem SMS. Do uwierzytelnienia się w systemie nie wystarczy wówczas wyłudzone bądź podsłuchane hasło, konieczny jest jeszcze kod jednorazowy przesłany na telefon komórkowy użytkownika. Przy okazji: €25,000 Bank Robbing Mobile Phones? oraz Kradnięcie SMS - myśli kilka.

Po uwierzytelnieniu

Dobrze, jeśli po uwierzytelnieniu system wyświetla w widocznym miejscu informację o dacie ostatniego logowania oraz, jeśli takie zdarzenie miało miejsce, informację o dacie ostatniej nieudanej próby logowania. Ta informacja pozwala zorientować się, że coś jest nie tak (daty logowań nie odpowiadają temu, co klient pamięta).

W niektórych systemach dostępne są "elementy antyphishingowe", które działają na zasadzie "dzielonego sekretu". Użytkownik wybiera element graficzny, który jest w stanie zapamiętać i rozpoznać. Jeśli po uwierzytelnieniu (lub w trakcie uwierzytelnienia, są różne implementacje) obrazek się nie pojawi, bądź pojawi się inny - może to sugerować, że użytkownik trafił na podrobioną stronę.

Co można zrobić bez autoryzacji

Intruz po ewentualnym złamaniu/przejęciu hasła (lub przejęciu sesji) nie powinien móc w systemie zrobić nic. W szczególności nie powinien móc wprowadzać żadnych zmian lub wykonywać operacji (przelewów). Wykonanie tego typu operacji powinno wymagać ich autoryzacji. Warto zwrócić uwagę, jakie operacje w danym systemie są możliwe do przeprowadzenia bez konieczności ich autoryzacji. Typowo dostępne są "przelewy zaufane", które sprowadzają się w praktyce do możliwości przelewu na wcześniej zdefiniowane konto, co może być uznane za kompromis między bezpieczeństwem i wygodą użytkownika. Według mnie każda inna operacja (nie koniecznie finansowa) powinna wymagać autoryzacji. Przykład - użytkownik posiada zdefiniowanych kilka szablonów transakcji, które jednak nie są oznaczone jako zaufane. Intruz loguje się na jego konto i modyfikuje wszystkie szablony tak, by przelew był realizowany na jego konto. Pytanie - ile osób sprawdza poprawność numeru konta przy realizacji przelewu na podstawie wcześniej zdefiniowanego szablonu? Nie robi się tego, ponieważ (niejawnie) zakłada się, że szablon nie był modyfikowany od czasu jego utworzenia.

Powiadomienia

Niektóre systemy oferują funkcje powiadomienia użytkownika o określonych zdarzeniach, na przykład o zalogowaniu się na konto, przelewie lub uznaniu większym niż określona kwota, (...). Warto wykorzystać ten mechanizm. Przy okazji warto zwrócić uwagę, czy mechanizm ten może zostać wyłączony bądź zrekonfigurowany bez autoryzacji.

Autoryzacja transakcji

O metodach autoryzacji transakcji również już pisałem wcześniej: O bezpieczeństwie bankowości elektronicznej - autoryzacja transakcji.

Obecnie jedyną metodą autoryzacji transakcji, która "broni się" przed malware (i tworzonym przez niego "matrixem") jest autoryzacja transakcji przy pomocy kodów SMS. Mowa o implementacji, w której dla każdej operacji przysyłany jest unikalny kod SMS wraz z informacjami na temat wykonywanej operacji. Użytkownik powinien zweryfikować, czy dane zawarte w SMS zawierają dane tej transakcji, która ma być wykonana. Trudno również podać "kilka kolejnych kodów" (jak to ma miejsce przy atakach typu phishing), jeśli użytkownik po prostu tych kilku kodów jeszcze nie ma. Podobnie jest zresztą w przypadku wykorzystania wskazania tokena, jednak w tym wypadku brak jest potwierdzenia parametrów transakcji. Jeśli w jakimś systemie wykorzystywane są nadal listy haseł jednorazowych, powoduje to, że klienci korzystający z tej metody autoryzacji transakcji stają się naturalnym obiektem ataku - po prostu atak na nich jest łatwiejszy, niż atak na klientów korzystających z kodów SMS.

Podsumowanie

Warto pamiętać, że większość przypadków "ataków na bankowość internetową" to w rzeczywistości ataki na klientów, a nie na sam system. Nie dlatego, że zaatakowanie systemu jest niemożliwe - po prostu zaatakowanie klientów (phishing, malware) jest łatwiejsze. Celem atakujących jest osiągnięcie łatwego zysku. Jeśli jest grupa potencjalnie łatwych ofiar, szansa na zaatakowanie tych "lepiej chronionych" jest mniejsza. Oczywiście sytuacja jest dynamiczna, to, co jest skuteczne dziś, nie musi być skuteczne jutro.