Matrix Green Code ProgrammingBardziej skomplikowane tokeny wykorzystują tzw. metodę challenge-response, czyli „hasło-odzew”. Na ekranie logowania serwer banku prezentuje nam losowy ciąg cyfr, który musimy wpisać na klawiaturce tokena. Token, korzystając z „zaszytego” w sobie tajnego klucza szyfrującego, przekształca wpisany ciąg cyfr na inny, który musimy przepisać z wyświetlacza tokena w odpowiednie pole na stronie WWW. Jeżeli klucz w tokenie będzie zgodny z kluczem przechowywanym na serwerze, system zweryfikuje naszą tożsamość i umożliwi nam dostęp do konta. Tego rodzaju tokenów używają Pekao SA, PKO BP i WBK.

Część banków rezygnuje z dodatkowego wsparcia sprzętowego i opiera swoje (a właściwie swoich klientów) bezpieczeństwo na kryptografii realizowanej środkami programowymi. Do tej grupy należą BPH i Fortis Bank. Pierwszy z nich stosuje własną metodę uwierzytelniania użytkownika, polegającą na wygenerowaniu – za pomocą specjalnego apletu Javy – podczas składania wniosku przez klienta pary kluczy: prywatnego i publicznego. W zależności od decyzji użytkownika, klucz prywatny, zaszyfrowany znanym tylko użytkownikowi hasłem, może być albo przechowywany na serwerze banku, albo na dysku komputera użytkownika lub dyskietce. Klucz publiczny jest natomiast rejestrowany w systemie bankowym. Podczas późniejszego logowania do systemu bądź potwierdzania wydanej dyspozycji aplet obsługujący logowanie podpisuje przesyłane do serwera dane zdekodowanym kluczem prywatnym (użytkownik musi podać hasło zabezpieczające klucz), a serwer banku weryfikuje ten podpis przy użyciu klucza publicznego. W świetle niedawnego odkrycia czeskich kryptologów związanego z bezpieczeństwem podpisu elektronicznego, raczej nie należy polecać opcji przechowywania klucza na serwerze, natomiast opcja z kluczem na dysku twardym, a zwłaszcza na odpowiednio chronionej dyskietce, może być uznana za dostatecznie bezpieczną.

System Fortis Banku wykorzystuje natomiast standardowe możliwości protokołu SSL w postaci tzw. certyfikatów prywatnych. Tu również podczas rejestracji w systemie następuje wygenerowanie i zapisanie na dyskietce pary kluczy. Klucz publiczny zostaje dodatkowo przesłany do banku, który podpisując go swoim kluczem prywatnym generuje certyfikat, potwierdzający tożsamość użytkownika. Certyfikat ten klient otrzymuje na dyskietce przy zawieraniu umowy i musi zainstalować go sobie w swojej przeglądarce WWW, aby móc zalogować się do systemu. Utworzona wcześniej dyskietka z kluczem prywatnym potrzebna jest natomiast przy akceptacji każdej dyspozycji.

Handlobank i mBank zrezygnowały natomiast z zaawansowanych technik kryptograficznych powierzając bezpieczeństwo pieniędzy klientów jedynie systemowi haseł. W Handlobanku bezpieczeństwa transakcji strzeże jedynie „zwykły” login i hasło. W mBanku potencjalnie niebezpieczne operacje są chronione dodatkowymi hasłami jednorazowymi, których listę wcześniej bank przesyła klientowi pocztą. Każde hasło z listy wykorzystywane jest do jednej operacji, po czym traci ważność – do następnej operacji należy wykorzystać kolejne hasło. Po wykorzystaniu wszystkich haseł możemy przez Internet lub telefonicznie zamówić kolejną ich listę.

Rzecz jasna wszystkie banki stosują szyfrowanie transmisji między przeglądarką a serwerem przy użyciu SSL ze 128-bitowym kluczem szyfrującym. Warto tu zwrócić uwagę na pewną niedogodność związaną z systemem PKO BP. Serwer tego banku posiada certyfikat SSL wystawiony przez polskie centrum certyfikacyjne UNIZETO (http://www.certum.pl/), który nie jest automatycznie rozpoznawany przez przeglądarki WWW. Powoduje to przy pierwszym połączeniu wyświetlenie przez przeglądarkę okienka ostrzegającego o nieznanym wystawcy certyfikatu, co może być dezorientujące dla użytkownika, a co gorsza, uniemożliwia automatyczne włączenie szyfrowania 128-bitowego w inych niż najnowsze (IE 5.5, Netscape 4.7) wersjach przeglądarek, w wyniku czego serwer banku odrzuca połączenie. Niezbędne jest zatem nie tylko zainstalowanie certyfikatu UNIZETO w przeglądarce, ale na dodatek konieczne może być pobranie odpowiednich poprawek do przeglądarki ze stron producenta. Niezrozumiałe jest, dlaczego właściwie PKO BP nie zdecydowało się na wykupienie – tak jak inne banki – certyfikatu wystawionego przez firmy takie jak Verisign lub Thawte, automatycznie akceptowanego przez przeglądarki – bo przecież na pewno przeszkodą nie były względy finansowe.
Na zakończenie kilka słów należy się kwestii dostępności systemów bankowości internetowej. Aby były one maksymalnie dostępne, nie powinny zbytnio ograniczać klienta pod względem wersji przeglądarki czy systemu operacyjnego. Oczywiście przeglądarka musi obsługiwać SSL, ale wszelkie dalsze wymagania są już niekonieczne. Pod tym względem wyróżnia się system Pekao SA, z którego da się – co wielokrotnie sprawdziłem – korzystać za pomocą dosłownie każdej przeglądarki obsługującej SSL (także z kluczem 40-bitowym – oczywiście szyfrowanie połączenia jest wtedy słabsze), nawet działającego w trybie tekstowym Lynxa. W wielu systemach wymagana jest jednakże dodatkowo obsługa Javascriptu 1.2 (wersja ta obsługiwana jest przez przeglądarki IE i Netscape od 4.0 wzwyż), zaś system Fortis Banku z uwagi na stosowanie na stronach skomplikowanych rozwiązań dynamicznego HTML-a wymaga najnowszych wersji przeglądarek. Najbardziej ogranicza użytkownika BPH – tu nie wystarczy użycie odpowiednio nowej wersji Internet Explorera lub Netscape, lecz na dodatek przeglądarki te muszą działać na platformie Windows – wprawdzie teoretycznie aplety Javy powinny być niezależne od systemu, jednak aplet realizujący generowanie klucza i logowanie do systemu BPH okazuje się być niezgodny z innymi środowiskami niż Windows. Zresztą bank na swoich stronach WWW nic nie wspomina o możliwości pracy w innym systemie… Dla użytkowników np. Linuxa czy komputerów Macintosh droga do systemu BPH Sez@m jest zatem zamknięta.

Zobacz też czym charakteryzują się dyski fibrowe.