Source: https://czasopismo.legeartis.org/2019/09/autoryzacja-transakcji-kodem-autoryzujacym.html
Timestamp: 2019-09-18 15:45:55+00:00
Document Index: 92110822

Matched Legal Cases: ['art. 4', 'art. 97', 'art. 5', 'art. 4', 'art. 4', 'art. 43', 'art. 43', 'artą 30']

Autoryzacja transakcji kodem autoryzującym przesłanym SMS (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 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.
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);
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 (…)
„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);
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).
Tags: art. 43 uup bank finanse PSD2 telekomunikacja usługi płatnicze
← Odbiorca płatności nie może ograniczać konsumentom spoza własnego kraju prawa do skorzystania z SEPA (C-28/18)
Sankcja darmowego kredytu konsumenckiego →
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.
Bez szans na powodzenie; natomiast zastanawiam się czy autoryzacja telefoniczna — dzwonię do banku z *zarejestrowanego* numeru („posiadanie”) i podaję *moje hasło* („wiedza”), wówczas bank udostępnia mi kod autoryzacyjny do *określonej transakcji*. (Inna sprawa, że to wymagałoby sprawności, a RTS generalnie przewiduje skracanie zalogowanej sesji.)
Identyfikacja numeru dzwoniącego nie jest skutecznym zabezpieczeniem (spoofing nie jest może trywialny ale też nie jest specjalnie trudny).
W sumie (chyba) racja — aż strach, że nie da się zrobić takiego systemu „odbierającego”, który będzie umiał odkryć takie sztuczki…
Jest gorzej – teraz przestępcy „spoofują” głos rozmówcy :) https://www.forbes.com/sites/jessedamiani/2019/09/03/a-voice-deepfake-was-used-to-scam-a-ceo-out-of-243000/
Terminator, jak babcię kocham. :D
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:
(…) 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.
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.
Ja się nie znam, ale jeśli bank A potrafi, bank B potrafi, bank C potrafi — to bank T też powinien potrafić. (Generalnie jest dla mnie, mimo wszystkich wad takiej metody, niewyobrażalne wyłączenie takiej opcji.)
Z ciekawości – dlaczego niewyobrażalne?
Nie wyobrażam sobie skutku w postaci cyfrowego wykluczenia chyba nie tak małej części klientów — na dziś sprowadzałoby się to do udostępnienia pełnej funkcjonalności bankowości internetowej tylko posiadaczem smartfonów z systemami Android i iOS. Chyba że bank byłby tak uprzejmy i zaczął wydawać (choćby odpłatnie) tokeny online.
Generalnie rozumiem, że jak się ma dostęp przez internet to nie można sarkać, że „nie będzie już przepisywania cyferek z karteluszek”, ale ew. zmuszenie do wyboru między Góglem i Ejplem byłoby sprzeczne z warunkiem zachowania neutralności technologicznej.
Ciekawostka: w moich papierach znalazłem zawartą 30 listopada 2001 r. umowę z BRE Bankiem (to był czas, że jeszcze byłem w miarę early-adopterem) wraz z nieotwartą kopertą zawierającą listę kodów jednorazowych (data wysyłki 23.07.2004 r.).
Nie wiem czy taka koperta miałaby kiedyś jakąkolwiek wartość kolekcjonerską — otworzyłem, zdjęcie dołożyłem do tekstu ;-)
Co właściwie pozwala na tezę, że jednak Toyota Bank naruszyła obowiązek zachowania neutralności technologicznej.
Czas pomyśleć o tekście o odpowiedzialności za naruszenie obowiązków wynikających z PSD2 — w tym przypadku być może patrząc przez pryzmat jakiegoś działania antykonsumenckiego?
Myślę, że TB jak każdy inny wie jakich ma klientów i podejmując taką czy inną decyzję wie jaki procent to uderzy (zgaduję, że niewielki) – mając na przeciwnej szali grube tysiące monet na smsy. Zgaduję, że jest to mniejszy procent niż opisujący liczbę klientów bez żadnej komórki w Pekao ;)
Natomiast co do neutralności – to przecież z jednej strony Android+iOS obejmują 99% rynku a z drugiej od zawsze banki porzucają wsparcie dla starych/niepopularnych rozwiązań (nie da się wejść na stronę banku z Internet Explorera 6 na Windowsie XP).
Pal sześć jakiś tam bank, natomiast myślę, że takie zaklinowanie się systemu mogłoby skutkować niechęcią do tworzenia alternatywnych rozwiązań (nie będę tworzył swojego iRudakOS, bo nie da się go użyć do autoryzacji usług bankowych, więc ludzie nie kupią moich telefonów).
Na Windows XP chyba nadal da się zainstalować Firefoksa czy Chrome? Więc taki użytkownik nie jest w 100% ugotowany.
“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.
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 »
Moim zdaniem procedura pt.
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
sprowadza się do odwrócenia relacji: kod generujesz na podstawie PIN + nr rachunku + kwota — ale to nie „operator” podaje dane transakcji („teraz płacisz 10 euro za pralinki w sklepie Vandaamma”), bo ja tak właśnie rozumiem wymóg tego dynamicznego łączenia i informowania.
Zgadzam się z RedNaczem, to Bank ma generować kod i informować za co klient „płaci”, a nie klient powiadamiać Bank.
Tym bardziej, że w ten sposób autoryzujemy tylko kwotę, a nie odbiorcę płatności.