Jeszcze o BPH Sez@m

Nie wszystko złoto...

... co się świeci, nie wszystko, co pięknie prezentuje się w materiałach marketingowych firmy, równie pięknie wygląda w rzeczywistości. W numerze 12/99 MI ukazała się notatka o uruchomieniu przez bank BPH systemu BPH Sez@m - "pierwszego w Polsce zintegrowanego systemu bankowości internetowej" (swoją drogą, w jakim sensie pierwszego w Polsce, skoro od października 1998 r. funkcjonuje z powodzeniem system bankowości internetowej banku PEKAO S.A. ?). Po jej ukazaniu się otrzymałem od kilku czytelników grup dyskusyjnych pl.comp.security i pl.biznes.banki, na których to grupach wcześniej wypowiadałem się na temat tego systemu, e-maile zawierające posądzenia o - nazwijmy to delikatnie - dwulicowość. Rzecz w tym, że moje wypowiedzi na grupach dyskusyjnych dotyczące tego systemu były bardzo krytyczne, zaś notatka w MI przesycona była wręcz entuzjazmem dla zaproponowanego przez BPH rozwiązania.

Wyjaśniam więc publicznie (co już zresztą wyjaśniałem moim korespondentom), że nie byłem autorem notatki zamieszczonej w MI, a z tego, co mi wiadomo, notatka ta napisana została w oparciu o informacje prasowe przekazane redakcji przez firmę Optimus Pascal Multimedia S.A., jeszcze przed uruchomieniem systemu BPH Sez@m. Tak to czasami mści się zawierzanie materiałom marketingowym zamiast własnoręcznemu sprawdzeniu... W tym przypadku to sprawdzenie nie było jednak możliwe, jako że system BPH Sez@m został uruchomiony 8 listopada 1999 r. - już po zamknięciu grudniowego numeru MI.

Moje zdanie na temat systemu BPH Sez@m pozostało niezmienione - uważam, iż wbrew temu, co głosiła notatka w MI, jest to system mało bezpieczny. Postaram się pokrótce wyjaśnić dlaczego.

Fakt zastosowania technologii kluczy prywatnych i publicznych RSA sam z siebie nie gwarantuje jeszcze żadnego bezpieczeństwa. Ogólnie znaną prawdą dotyczącą tej technologii jest fakt, że jej bezpieczeństwo zależy przede wszystkim od należytego zabezpieczenia dostępu do klucza prywatnego. We wzorcowej realizacji tej technologii (z jaką mamy do czynienia np. w programie PGP, czy przy stosowaniu tzw. osobistych certyfikatów SSL w przeglądarkach WWW) klucz prywatny nie powinien nigdy opuszczać komputera użytkownika. Rozwiązanie BPH jest jednak inne: tu klucz prywatny nie znajduje się na naszym komputerze, lecz - zaszyfrowany szyfrem 3DES - przechowywany jest na serwerze banku, skąd jest nam przesyłany każdorazowo przy próbie logowania. Bezpieczeństwo klucza sprowadza się zatem do bezpieczeństwa hasła umożliwiającego jego odszyfrowanie, a to już znacznie niższy poziom bezpieczeństwa. Fakt stosowania kluczy staje się w takim rozwiązaniu na dobrą sprawę wyłącznie drugorzędną kwestią techniczną; z punktu widzenia użytkownika zabezpieczeniem konta są jedynie dwa hasła - jedno do serwera, drugie do odkodowania klucza.

W tym momencie trzeba wspomnieć, że system BPH Sez@m działa wyłącznie z przeglądarką Internet Explorer 4.0 (lub wyższą) w środowisku Windows 95/98, z uwagi na stosowanie technologii ActiveX. Już sam fakt stworzenia systemu dającego się poprawnie obsługiwać tylko jedną przeglądarką w tylko jednym środowisku w mojej opinii jest kompromitacją: napisy typu "oglądać tylko przeglądarką XYZ" można od biedy tolerować na amatorskiej stronie skleconej przez "niedzielnego webmajstra", ale są one nie do przyjęcia w poważnym systemie bankowości internetowej poważnego banku (jakoś i PEKAO S.A., i wiele banków zagranicznych, których strony WWW miałem okazję oglądać, nie miały problemów z utworzeniem systemów dających się obsługiwać nawet tekstowym Lynxem...). Mniejsza jednak z tym; poważniejszym problemem jest fakt, że technologia ActiveX, na której opiera się cały mechanizm uwierzytelniania użytkownika w BPH Sez@m, sama stanowi jedno wielkie zagrożenie bezpieczeństwa Windows! Znakomita większość odkrytych "dziur" w bezpieczeństwie Windows 95/98 związana jest właśnie z ActiveX - jest ich tyle, że specjaliści od komputerowego bezpieczeństwa często zalecają dla bezpiecznego korzystania z Internetu wyłączenie w ogóle w MSIE obsługi komponentów ActiveX.

Dowolny komponent ActiveX, który z jakiejkolwiek strony WWW załaduje się do naszego komputera, ma pełny dostęp do jego zasobów - może zrobić dosłownie wszystko. Można zaufać komponentom ładowanym ze strony banku, iż nie wykonują żadnych szkodliwych dla nas działań, jaką jednak możemy mieć gwarancję, że na zupełnie innej, pozornie zupełnie niewinnej stronie WWW, którą odwiedzimy wcześniej albo później, nie znajdzie się komponent, który np. zainstaluje nam w komputerze konia trojańskiego, przechwytującego i wysyłającego do jego autora wszystko to, co piszemy na klawiaturze? Albo wręcz podmieni komponenty wcześniej zainstalowane przez bank? W takiej sytuacji przechwycenie obydwu haseł strzegących dostępu do naszego konta nie jest już żadnym problemem... W zastosowaniach finansowych poziom bezpieczeństwa musi być najwyższy, a użycie do zapewnienia bezpieczeństwa technologii samej w sobie niezbyt bezpiecznej raczej nie wzbudza zaufania do systemu... Warto jeszcze wspomnieć o tym, że serwer banku BPH używa szyfrowanego połączenia SSL jedynie z 40-bitowym kluczem (bardzo to dziwne, gdyż banki na całym świecie bez problemu mogą uzyskać certyfikat Global Server ID, umożliwiający stosowanie szyfrowania 128-bitowego - certyfikat taki ma np. wspomniany już system PEKAO S.A.), która to długość klucza - jak powszechnie wiadomo - nie zapewnia praktycznie żadnego zabezpieczenia przed rozkodowaniem transmisji nawet przez hackera-amatora.

Podsumowując to wszystko, osobiście zdecydowanie odradzałbym powierzanie swoich pieniędzy systemowi BPH Sez@m. Pytaniem bez odpowiedzi pozostaje, dlaczego bank BPH nie zdecydował się np. na zastosowanie najpopularniejszej w systemach bankowości internetowej na całym świecie metody zabezpieczenia za pomocą tzw. tokenów (generatorów jednorazowych haseł - kod wyświetlony na wyświetlaczu tokena trzeba wpisać na stronie WWW, aby się zalogować do systemu), tylko na tak zawikłany i mało bezpieczny sposób?


Jarosław Rafa 1999. Tekst udostępniony na licencji Creative Commons (uznanie autorstwa - użycie niekomercyjne - bez utworów zależnych). Kliknij tutaj, aby dowiedzieć się, co to oznacza i co możesz z tym tekstem zrobić. W razie jakichkolwiek wątpliwości licencyjnych bądź w celu uzyskania zgody na rozpowszechnianie wykraczające poza warunki licencji proszę o kontakt e-mailem: raj@ap.krakow.pl.

Wersja HTML opracowana 22.02.2000.


Powrót do wykazu artykułów o Internecie Statystyka