Paweł Goleń, blog

Na początku ustalenie kilku rzeczy. Przez uwierzytelnienie użytkownika rozumiem pierwszy etap interakcji użytkownika z serwisem bankowości internetowej, w której użytkownik "przedstawia się" systemowi, tak, by system mógł zidentyfikować kto się do niego dostaje. Za autoryzację transakcji uznaję potwierdzenie przez użytkownika tego, że rzeczywiście chce on wykonać transakcję o określonych parametrach.

Uwierzytelnienie użytkownika

Uwierzytelnienie użytkownika to podanie swojej nazwy i... i jeszcze czegoś. W chwili obecnej chyba najbardziej rozpowszechnione są następujące metody uwierzytelnienia:

• hasło,
• hasło maskowane,
• podpis cyfrowy,

W przypadku hasła podawane jest za każdym razem całe hasło użytkownika. W przypadku hasła maskowanego podawane są jedynie niektóre jego znaki. Podpis cyfrowy opiera się w praktyce na proof-of-possession, o którym już wspominałem w tekście o SSL. Jaką metodę uznać za najbardziej bezpieczną? W pierwszej chwili odpowiedź jest jasna - oczywiście, że podpis cyfrowy... Tylko, że po dłuższym zastanowieniu okazuje się, że wcale tak nie jest. Ale po kolei.

Hasło jest złe!

Dlaczego? Ponieważ może zostać podsłuchane, podpatrzone, zalogowane przez jakiegoś key-loggera, przechwycone przez konia trojańskiego... Wystarczy raz skorzystać z niezaufanej stacji lub nie zwrócić uwagi na kogoś nader intensywnie zaglądającego przez ramię i hasło wpada w niepowołane ręce. Tylko co z tego?

Prawidłowo zaprojektowana bankowość elektroniczna nie powinna temu komuś pozwolić na nic więcej, niż tylko przeglądnięcie danych. Oczywiście, nie jest to coś dobrego, ale czasami z takim ryzykiem trzeba się pogodzić... Do autoryzacji transakcji wymagane jest coś innego niż hasło (no, pominę jakieś śmieszne systemy bankowości elektronicznej z Koziej Wólki).

Podpis cyfrowy wcale nie jest lepszy, chyba, że klucze przechowywane są na karcie kryptograficznej. Nie koniecznie musi to być karta kryptograficzna, może to być dowolne urządzenie, które w sposób bezpieczny przechowuje klucz prywatny, wykonuje za jego pomocą wskazane operacje, ale NIGDY nie "wypuszcza go" z siebie.

Przechowywanie klucza na dyskietce, kluczu USB czy dysku to rzecz praktycznie bez różnicy. Jeśli kiedykolwiek skorzystamy z niezaufanego komputera, to mamy problem. Klucz może zostać skopiowany, hasło do klucza podsłuchane... i jesteśmy w sytuacji gorszej niż w przypadku pierwszej metody uwierzytelnienia, ponieważ jeśli do uwierzytelnienia wykorzystywany jest podpis cyfrowy, to ta sama technika jest wykorzystywana również do autoryzacji transakcji. Chwila nieuwagi i atakujący może nie tylko zalogować się do systemu bankowości elektronicznej, ale, co gorsza, wykonać w nim dowolną operację.

Osoby świadome zagrożeń unikają korzystania z niezaufanych komputerów, niestety większość użytkowników bankowości elektronicznej do świadomych się nie zalicza... Efekt - podpis cyfrowy, mimo że teoretycznie jest najsilniejszą metodą uwierzytelnienia, w praktyce jest też metodą najbardziej ryzykowną, jeśli w odpowiedni sposób nie zostanie zabezpieczony klucz prywatny, czyli powtarzam - nie będzie on chroniony przed skopiowaniem poprzez umieszczenie go na karcie kryptograficznej, lub innym urządzeniu działającym na analogicznej zasadzie.

Hasło maskowane

jest lepsze... Samo w sobie nie jest wykorzystywane do autoryzacji transakcji, dopiero wielokrotne skorzystanie z niezaufanego komputera może skutkować ujawnieniem pełnego hasła, ponieważ za każdym razem wpisywane są jedynie niektóre znaki hasła (z dokładnością do przypadku, gdy ktoś akurat zmienia hasło, wówczas siłą rzeczy podać musi pełne nowe hasło).

Co można zrobić lepiej...

Cóż, proponowałbym połączenie hasła maskowalnego z hasłem jednorazowym z listy, hasłem przesłanym SMS lub wskazaniem tokenu (lub innego urządzenia o analogicznej funkcjonalności). Dlaczego łączyć? Osiągamy wówczas klasyczny przykład "coś co wiesz" (hasło maskowane) i "coś co masz" (lista haseł, przesłane przez SMS hasło, wskazanie tokenu).

Dlaczego nie sama druga część? Ponieważ wówczas w przypadku utraty listy (ktoś ukradnie portfel), kradzieży komórki lub tokenu atakujący może dysponować wystarczającymi informacjami, by próbować dostać się do konta. Tutaj wyjątkiem może być token, który przed pokazaniem swojego wskazania wymaga wpisania kodu PIN.

Ciekawym rozwiązaniem jest UCR (Unconnected Card Reader). Jest to małe urządzenie, do którego wkłada się kartę EMV i... i reszta zależy od aplikacji na karcie. Można wyobrazić sobie taki scenariusz, że serwis bankowości elektronicznej po podaniu loginu przez użytkownika na kolejnym ekranie wyświetla pewien challenge. Użytkownik przepisuje ten challenge do UCR, który po podaniu kodu PIN wyświetla response, użytkownik przepisuje wyliczony response do formatki na stronie i loguje się do serwisu.

W Polsce takie rozwiązanie spotkać się może z jednym problemem - małe upowszechnienie kart EMV, niektóre banki posiadające bankowość elektroniczną, nie posiadają kart EMV w swojej ofercie. Druga sprawa - opór materii, czyli klientów. Dla klientów jest to kolejne (niewielkie) urządzenie, a dla wielu z nich bankowość elektroniczna ma być dostępna gdziekolwiek, na przykład na plaży, gdy taki klient jest w samych slipkach/stroju kąpielowym (a czasami i bez), gdzie wówczas schować taki UCR, o karcie nie wspominając? Warto wspomnieć natomiast, że samo rozwiązanie proponowane przez UCR nie jest nowatorskie, już wcześniej były dostępne podobne rozwiązania, gdzie rolę urządzenia wyliczającego response pełnił token. Tutaj nowością jest możliwość osadzenia dowolnej aplikacji na karcie EMV przez bank.