Kod autoryzujący przesłany esemesem a dyrektywa PSD2

Zagadnęła mnie zaniepokojona P.T. Czytelniczka: Toyota Bank zapowiedział, że od 14 września nie będzie możliwa autoryzacja transakcji płatniczych przy pomocy kodów autoryzujących przesyłanych esemesem na komórkę klienta — bo dyrektywa PSD2 nie uznaje takiej formy za silne uwierzytelnienie użytkownika. Czy to oznacza, że inne banki — te, które zapowiadają, że nadal będzie można autoryzować płatność przy użyciu przepisywanych kodów — nie zamierzają prawidłowo wdrożyć PSD2?


autoryzacja transakcji kodem autoryzującym

Autoryzacja transakcji kodem autoryzującym nie oznacza konieczności przepisywania cyferek otrzymanych w esemesie — kodem autoryzującym jest także „automagiczny” kod przesłany przez aplikację mobilną


Zaczynając od początku: postanowiłem, tak jak lubię, sięgnąć do źródła, czyli do opublikowanej przez ten bank informacji prasowej zatytułowanej „Nowa bankowość internetowa oraz sposób autoryzacji transakcji w Toyota Bank”. W dokumencie tym czytamy:

Na podstawie analiz prawnych wykonanych przez Toyota Bank, aplikacja mobilna w bankowości elektronicznej jest obecnie jedynym sposobem na pełną realizację wymogów bezpieczeństwa, określonego nowymi przepisami. Nie spełniają ich zarówno stosowane dotychczas tokeny sprzętowe –- z uwagi na brak powiadamiania o kwocie transakcji oraz danych odbiorcy, jak i również SMS-y — szczególnie w zakresie wypełnienia wymogu, aby wszelkie zmiany kwoty lub odbiorcy skutkowały unieważnieniem wygenerowanego kodu uwierzytelniającego z powodu braku kontroli nad raz wysłanym kodem SMS. Z tego względu, ta forma autoryzacji nie była brana pod uwagę w trakcie analiz nad wdrożeniem wymogów ustawy. Wcześniejsze wdrożenie zapewnia klientom elastyczne przejście na nową formę autoryzacji transakcji. Jednocześnie zapewniamy, że zarówno teraz, jak i po 14 września nasi klienci wciąż będą mieli dostęp do bankowości w formie telefonicznej.

Moim zdaniem ta wypowiedź może być prawdziwa — ale budowanie na jej podstawie ogólnych wniosków prowadzi do nieprawdziwych konkluzji.

Zaczynając od początku, w punktach:

  • dyrektywa 2015/2366 nie zakazuje stosowania esemesów jako sposobu przesyłania elementu weryfikacyjnego należącego do kategorii „posiadanie” (art. 4 pkt 30 dyrektywy PSD2) — natomiast wymaga, by metody silnego uwierzytelniania klienta stosowane przy elektronicznych zdalnych transakcjach płatniczych „dynamicznie łączyły” transakcję z jej kwotą i jej odbiorcą (art. 97 ust. 2 PSD2),
  • szczegółowe wymogi i technikalia wykonania PSD2 opisane są w rozporządzeniu delegowanym 2018/389 (tzw. RTS — to jest ten sam dokument, który zezwolił na pewne wyjątki od stosowania silnego uwierzytelniania), który wprost wskazuje, że stosowane kody uwierzytelniające muszą być bardzo bezpieczne, ale nie można instytucjom finansowym narzucać żadnych konkretnych rozwiązań (Dynamiczne łączenie można uzyskać poprzez generowanie kodów uwierzytelniających, które podlega zestawowi restrykcyjnych wymogów bezpieczeństwa. Aby zapewnić neutralność pod względem technologicznym, nie należy wymagać stosowania konkretnej technologii do celów wdrożenia kodów uwierzytelniających”, motyw 4 RTS);
art. 43 ustawy o usługach płatniczych
1. Dostawca wydający instrument płatniczy jest obowiązany do:
1) zapewnienia, że indywidualne zabezpieczenia instrumentu płatniczego nie są dostępne dla osób innych niż użytkownik uprawniony do korzystania z tego instrumentu (…)
2. Dostawca ponosi ryzyko związane z wysłaniem płatnikowi instrumentu płatniczego lub jego indywidualnych zabezpieczeń.
  • „dynamiczne połączenia” to nic innego jak m.in. wymóg stałego połączenia kwoty i odbiorcy z konkretną operacją. Bankowcy mają obowiązek zapewnić te wymogi poprzez: (i) poinformowanie klienta o kwocie płatności i jego odbiorcy; (ii) przypisaniu wygenerowanego kodu do konkretnej transakcji (kwoty i odbiorcy); (iii) każda zmiana kwoty lub odbiorcy powoduje unieważnienie kodu — toteż dostawcy usług płatniczych muszą zagwarantować stałą „poufność, autentyczność i integralność” informacji o kwocie i odbiorcy na wszystkich etapach uwierzytelniania (generowania kodu, jego przekazywania i wykorzystywania, art. 5 RTS); co więcej kod uwierzytelniający może być wygenerowany wyłącznie po prawidłowym podaniu co najmniej dwóch elementów (spośród „wiedzy”, „posiadania” i „cech klienta”); zaś każdy kod może być zastosowany tylko jeden raz (art. 4 ust. 1 RTS);
  • warunkiem uznania, iż stosowane przez bank rozwiązania w zakresie kodu są bezpieczne, jest to, iżby: (i) treść kodu uwierzytelniającego nie ujawniała żadnych informacji o „wiedzy”, „posiadaniu” lub „cechach”; (ii) wygenerowanie kodu nie było możliwe na podstawie znajomości żadnego wcześniejszego kodu; (iii) kod uwierzytelniający był niemożliwy do sfałszowania; (iv) odmawiając wygenerowania kodu uwierzytelniającego system nie może informować o tym, który z elementów (hasło? login? biometria?) był błędny; (v) stała lub czasowa blokada dostępu do usług następowała po co najwyżej 5 błędnych próbach w określonym czasie (czyli bank ma prawo blokować kanał już po 2 błędach);

autoryzacja transakcji kodem autoryzującym

Ciekawe, że w moich papierzyskach uchowała się nieotwarta (!) koperta z listą haseł jednorazowych. Nie pamiętam kiedy mBank umożliwił potwierdzenie operacji esemesami — na pewno tę przesyłkę wysłano do mnie w lipcu 2004 r., ale najwyraźniej już nie była mi potrzebna (ale być może dlatego, że miałem w użyciu wcześniejszą listę) (fot. Olgierd Rudak, CC-BY-SA 3.0)


  • w każdym natomiast przypadku bank musi uczyć się na bieżąco, nawet na swoich własnych błędach i starać się wygrać wyścig zbrojeń z oszustami — analizować ryzyko: monitorować i wykrywać nieautoryzowane operacje, analizować działania każdego użytkownika, rozpracowywać scenariusze oszustw, reagować na sygnały wskazujące na obecność złośliwego oprogramowania; a jeśli audyt wdrożonych środków bezpieczeństwa dowiedzie, że rozwiązania nie spełniają wymogów wynikających z PSD2.

Jak to wszystko ma się do przekazanej przez Toyota Bank informacji, że autoryzacja transakcji kodem autoryzującym przesłanym w wiadomości SMS nie spełnia wymogów bezpieczeństwa? Moim zdaniem bardzo prosto, acz hipotetyczne odpowiedzi są dwojakie:

  • skoro sposób autoryzacji musi nieść informację o tym komu i ile mamy zapłacić, to rzeczywiście tokeny offline są na straconej pozycji (oczywista oczywistość);
  • jednakże w pozostałej części bank wydaje się mówić: nasz system nie umie zagwarantować odpowiedniego poziomu bezpieczeństwa — nie potrafimy tak go zapojektować, by podmiana odbiorcy lub zmiana kwoty płatności skutkowała unieważnieniem kodu autoryzacyjnego;
  • natomiast co do „braku kontroli nad raz wysłanym kodem SMS” — to jasne, że nie wiemy kto rzeczywiście będzie miał w ręku telefon z numerem zarejestrowanym przez klienta (ale ani w PSD2 nie o to chodzi) — natomiast wydaje mi się, że w ten sposób bank delikatnie się przyznaje, że nie chce mu się pracować nad tym, by kanał ten nie był podatny na manipulację ze strony osób niepowołanych (zwracam uwagę, że regulacja nie nakazuje tutaj stawać na głowie — wystarczy wdrożyć środki techniczne określone w rozdziale V rozporządzenia, por. art. 4 ust. 2 lit. c RTS);
  • może być jednak nieco inaczej, bo może się okazać, że Toyota Bank już dziś — wszakże bankowość elektroniczna funkcjonuje nie od dziś i bolączki związane z płatnościami nieautoryzowanymi choć potwierdzonymi kodami dostarczanymi via SMS też już dobrze znamy — przeprowadziła audyt środków bezpieczeństwa, zaś jego wyniki doprowadziły do wniosku, że rzeczywiście autoryzacja transakcji kodem autoryzującym przesłanym klientowi w esemesie na numer komórki nie zapewnia wymaganego poziomu ochrony (ba, powołanie się na „analizy prawne” wskazuje, że szacowano ryzyko tego rodzaju — jakby na to nie patrzeć przepis o odpowiedzialności banku za bezpieczeństwo indywidualnych zabezpieczeń instrumentu płatniczego nadal będzie obowiązywał (art. 43 uup).

19
Dodaj komentarz

avatar
5 Comment threads
14 Thread replies
2 Followers
 
Most reacted comment
Hottest comment thread

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
najnowszy najstarszy
Powiadom o
Imię
Gość
Imię

Ciekawie będzie jak ktoś pozwie bank za wymuszanie kupienia telefonu komórkowego, bo ktoś może nie mieć i korzystać ze zdrapek lub odczytywać SMS’y za pomocą modemu wpiętego do komputera.

marcin
Gość
marcin

W kontekście nadchodzących zmian warto (jeśli kogoś to interesuje) zapoznać się z interpretacją RTS-ów dostarczaną przez EBA (European Banking Authority), np. https://eba.europa.eu/documents/10180/2622242/EBA+Opinion+on+SCA+elements+under+PSD2+.pdf oraz obszerny zestaw Q&A – np. w temacie SMS-ów:
https://eba.europa.eu/single-rule-book-qa/-/qna/view/publicId/2018_4039

(…) one-time password sent via SMS would constitute a possession element and should therefore comply with the requirements under Article 7 of these RTS, provided that its use is ‘subject to measures designed to prevent replication of the elements’, as required under Article 7(2) of these RTS. The possession element would not be the SMS itself, but rather, typically, the SIM-card associated with the respective mobile number.

RYBY
Gość
RYBY

Być może SMSy z Toyota Banku zawierały w treści tylko kod autoryzacji, a nie wszystkie wymagane elementy.
A może koszt wysyłania setek tysięcy SMS do Klientów okazał się za duży dla tego banku.

mmm777
Gość
mmm777

“Zmiany nie powinny przysporzyć problemów klientom bankowości, mają za to ograniczyć liczbę fraudów i wyłudzeń.”
.
Mam nadzieję, że ktoś to sprawdzi.

Prozrepina
Gość
Prozrepina

Szczersze mówiąc, nie wiem, dlaczego tak autorytatywnie stwierdziłeś „•skoro sposób autoryzacji musi nieść informację o tym komu i ile mamy zapłacić, to rzeczywiście tokeny offline są na straconej pozycji (oczywista oczywistość);” Posiadałem token offline w banku Montepaschi Belgio https://www.montepaschi.be/en/login/ który działa według następującej procedury: Token w dłoń (posiadanie), wpisujemy kod PIN (wiedza), przepisujemy 2 wygenerowane podczas płatności kody: 8 ostatnich cyfr rachunku bankowego (co przy 14 cyfrowych rachunkach w Belgii jest całkowicie wystarczające ;) ) i 8 cyfr reprezentujących kwotę przelewu (Euro i eurocenty). Wygenerowany w tokenie kod wpisujemy na stronie banku i zatwierdzamy przelew. https://www.montepaschi.be/questions/faq/paschiweb/ Nie ukrywam, że process… Czytaj więcej »