Wyzwania bankowe sumują się: PSD2 oznacza nowe zasady udostępniania danych

Opublikowany: 2018-04-13

Wielu z was bez wątpienia słyszało o dyrektywie Unii Europejskiej Europejskiego Urzędu Nadzoru Bankowego (lub EBA) o nazwie PSD2 (skrót od dyrektywy w sprawie usług płatniczych). Wytyczne te zostały pierwotnie opublikowane pod koniec 2015 r. Do stycznia 2018 r. wszystkie państwa członkowskie były zobowiązane do wdrożenia przepisów.

Branża bankowa stoi przed wieloma wyzwaniami, jeśli nie myśli już o bardzo cyfrowej przyszłości.

Zrozumienie silnego uwierzytelniania klienta dla PSD2 UE

Kluczowe cele PSD2 obejmują:

  1. Otwarcie nowych możliwości rynkowych dla różnych graczy, takich jak handlowcy online, przy jednoczesnym wyrównaniu szans dla wszystkich kluczowych interesariuszy
  2. Zapewnienie konsumentom przejrzystości i możliwości wyboru
  3. Wprowadzenie nowych i bardziej niezawodnych praktyk w zakresie bezpieczeństwa płatności online

Istnieje kilka ogólnych wytycznych dotyczących PSD2; jednak jedną z lepszych wytycznych PSD2 można pobrać z MEF (Mobile Ecosystem Forum).

Silne uwierzytelnianie klienta

Jednym z kluczowych elementów regulacji PSD2 jest koncepcja Silnego Uwierzytelnienia Klienta (lub SCA). EBA zauważa: „Dzięki PSD2 konsumenci będą lepiej chronieni podczas dokonywania płatności lub transakcji elektronicznych (takich jak korzystanie z bankowości internetowej lub zakupy online).

Regulacyjny Standard Techniczny (RTS) sprawia, że ​​silne uwierzytelnianie klienta (SCA) jest podstawą dostępu do rachunku płatniczego, a także dokonywania płatności online.” W skrócie SCA wymaga co najmniej uwierzytelniania dwuskładnikowego (2FA).

Uwierzytelnianie dwuskładnikowe oznacza, że ​​użytkownicy będą musieli „udowodnić” swoją tożsamość za pomocą dwóch oddzielnych elementów z trzech:

  1. Coś, co znają (kod PIN lub hasło)
  2. Coś, co posiadają (urządzenie mobilne, karta)
  3. Coś czym są (odciski palców, skan twarzy: np. biometria)

EUNB zauważa, że ​​SCA jest powszechnie stosowany w całej UE; jednak nie zawsze tak jest w przypadku transakcji płatniczych online, takich jak płatność kartą kredytową lub bezpośredni przelew bankowy. SCA jest stosowany w krajach UE w Belgii, Holandii i Szwecji); jednak w innych krajach UE SCA jest stosowany wyłącznie na zasadzie dobrowolności, jak wynika z doskonałego komunikatu prasowego Komisji Europejskiej.

Podczas gdy państwa członkowskie UE miały wdrożyć PSD2 do stycznia 2018 r., SCA stanie się obowiązkowe 18 miesięcy później po wprowadzeniu przez EBA Regulacyjnego Standardu Technicznego (RTS) po dacie wejścia w życie RTS (co ma nastąpić jeszcze w tym roku). . Zasadniczo patrzymy na połowę i koniec 2019 r. (wrzesień 2019 r. był jedną z takich terminów, które cytowały niektóre dokumenty). Dzięki temu wszyscy interesariusze będą mieli wystarczająco dużo czasu na włączenie SCA i innych wymagań bezpieczeństwa do swoich systemów i przepływów pracy.

Bankowość detaliczna: Lwy, bankierzy i fintechy, ojej!

retail_banking_fintech.jpg Fintechy zagrażają status quo. W przeciwieństwie do banków nie są obciążone zapisami, przepisami, a w większości przypadków nawet koniecznością zarabiania pieniędzy. Bankowcy detaliczni muszą dostosować się i skupić na relacjach z klientami, aby konkurować.

2FA dla SCA

Biorąc pod uwagę harmonogram SCA, rok 2018 to idealny czas dla firm, aby rozpocząć wdrażanie rozwiązań 2FA w celu uwzględnienia wymaganego zwiększonego bezpieczeństwa.

Międzynarodowa firma prawnicza Taylor Wessing w swoim artykule: Silne uwierzytelnianie klienta w ramach PSD2 zauważa, że ​​„EUNB zgodził się z większością respondentów w dokumencie konsultacyjnym, że w celu zapewnienia neutralności technologicznej i umożliwienia rozwoju przyjaznego dla użytkownika , dostępnymi i innowacyjnymi środkami płatniczymi, nie powinien dalej określać elementów uwierzytelniania.” Oznacza to, że EUNB nie precyzuje, w jaki sposób można wdrożyć 2FA. Istnieje wiele różnych schematów, w tym dostarczanie tokenów przez kanały mobilne, takie jak powiadomienia SMS lub push lub bardziej tradycyjne kanały e-mail, a także rozwiązania tokenów miękkich TOTP i inne.

Biorąc to wszystko pod uwagę, powinniśmy zwrócić uwagę, że jak każdy dobry schemat wdrażania 2FA, istnieją pewne ograniczenia i szczegółowe przepisy, które należy dokładnie rozważyć.

Kody uwierzytelniające

RTS zauważa, że ​​generowanie kodu uwierzytelniającego spełnia następujące warunki:

  1. Z ujawnienia kodu uwierzytelniającego nie można uzyskać informacji dotyczących wiedzy, posiadania i dziedziczenia
  2. Nie jest możliwe wygenerowanie nowego kodu uwierzytelniającego na podstawie znajomości innego wygenerowanego wcześniej kodu uwierzytelniającego
  3. Kod uwierzytelniający nie może zostać sfałszowany

Dodatkowo RTS stwierdza, że ​​nie więcej niż 5 nieudanych prób uwierzytelnienia należy podjąć w czasie życia kodu, a maksymalny czas bezczynności płatnika lub użytkownika po uwierzytelnieniu w celu uzyskania dostępu do jego rachunku płatniczego online nie może przekroczyć 5 minut .

Dynamiczne łączenie transakcji

RTS wskazuje, że elektroniczne transakcje zdalne – zasadniczo płatności dokonywane przez Internet (czy to na urządzeniu stacjonarnym, takim jak laptop czy urządzenie mobilne) muszą zawierać elementy, które „dynamicznie łączą transakcję z określoną kwotą i konkretnym odbiorcą”. RTS uważa to za dodatkową formę SCA.

W przypadku tego wymogu SCA kwota transakcji płatniczej oraz informacja o tym, kogo odbiorca (lub sprzedawca) należy przekazać użytkownikowi w momencie transakcji 2FA. W przypadku jakiejkolwiek zmiany kwoty lub odbiorcy należy wygenerować inny kod uwierzytelniający (np. „dynamiczne łączenie” tego kodu z nowym odbiorcą i/lub kwotą płatności). Wiadomość SMS ze wszystkimi wymaganymi informacjami może wyglądać jak na obrazku po prawej: 10-minutowy kod bezpieczeństwa, nazwa sprzedawcy (lub odbiorcy płatności) oraz kwota transakcji.

Co ciekawe, kod uwierzytelniający wygenerowany przez zewnętrzną aplikację zgodną z TOTP, taką jak Google Authenticator, jest generowany całkowicie niezależnie od informacji o płatności / sprzedawcy i dlatego nie można go dynamicznie łączyć.

Niezależność kanału

Ten wymóg jest nieco skomplikowany. RTS stwierdza, że ​​„dostawcy usług płatniczych powinni przyjąć środki bezpieczeństwa, w których którykolwiek z elementów silnego uwierzytelnienia klienta lub sam kod uwierzytelniający jest używany za pośrednictwem urządzenia wielofunkcyjnego, w celu ograniczenia ryzyka, które wynikałoby z tego urządzenia wielofunkcyjnego bycie skompromitowanym”. Urządzeniem wielofunkcyjnym może być urządzenie mobilne lub tablet, a nawet laptop.

Jeśli użytkownik korzysta z laptopa i jest proszony o dokonanie płatności, wówczas sprzedawca może wysłać SMS na urządzenie mobilne użytkownika z odbiorcą (np. akceptantem) oraz kwotą, jaką zamierza zapłacić, wraz z uwierzytelnieniem kod w treści SMS-a.

W innym przykładzie, jeśli użytkownik używa urządzenia mobilnego do interakcji ze sprzedawcą i inicjuje płatność, to ta niezależność od kanału nie zabrania konkretnie wiadomości SMS lub jakiegokolwiek kanału dostawy specyficznego dla telefonu komórkowego. Tutaj jest cienka linia. W wielu przypadkach jedynym urządzeniem, jakie posiada użytkownik, jest urządzenie wielofunkcyjne, takie jak telefon komórkowy. Ale niezależność kanału polega po prostu na tym, że – niezależny kanał na tym samym urządzeniu – SMS z kodem uwierzytelniającym to inny kanał (w rzeczywistości jest to kanał pozapasmowy , osiągalny przez numer telefonu komórkowego) niż telefon komórkowy aplikacja lub przeglądarka internetowa, z którą użytkownik kontaktuje się ze sprzedawcą. Ta sama niezależność od kanału miałaby zastosowanie do korzystania z aplikacji mobilnej do generowania kodu zgodnego z TOTP (takiego jak Google Authenticator), ale jak wspomniano wcześniej, kod skargi TOTP nie może dynamicznie łączyć transakcji.

I odwrotnie, jeśli użytkownik korzystał z aplikacji mobilnej, aby uzyskać dostęp do sprzedawcy, powiadomienie push do tej samej aplikacji (z kodem uwierzytelniającym) nie byłoby możliwe, ponieważ są to ten sam kanał.

Są tacy, którzy powiedzieliby, że 2FA przez SMS jest bardzo niebezpieczne, aw niektórych przypadkach może to być prawda. Tak, były pojedyncze przypadki, w których atakujący zdołał uzyskać dostęp do wiadomości SMS 2FA przez SS7 u jednego operatora; jednak wiele z tych luk zostało zamkniętych. Ponadto bardzo ważne jest, w jaki sposób kod uwierzytelniający jest generowany i dostarczany użytkownikowi oraz w jaki sposób dostawca usług przesyłania wiadomości dostarcza takie kody.

W sytuacjach, w których powszechne są urządzenia wielofunkcyjne (a dzisiaj są i nadal będą to najbardziej rozpowszechnione urządzenia), kanał przesyłania wiadomości dostarczany przez operatora komórkowego powinien nadal być opłacalnym kanałem pozapasmowym dla tokenów 2FA.

Aby uzyskać bardziej szczegółową analizę, znalazłem informacyjny post na blogu autorstwa Frederika Mennesa, który zawiera więcej szczegółów na temat tego, jakie typy scenariuszy – zwłaszcza w przypadku urządzeń wielofunkcyjnych – powinny być zgodne z PSD2 SCA.

PSD2 SCA nie należy lekceważyć, ale wiele już wdrożonych rozwiązań 2FA powinno działać; wiemy jednak również, że wielu sprzedawców internetowych nie oferuje jeszcze rozwiązań zgodnych z PSD2 SCA. W chwili pisania tego tekstu jest jeszcze wystarczająco dużo czasu na włączenie SCA do przepływów pracy związanych z płatnościami.

SAP Authentication 365 to rozwiązanie, które zapewnia rozwiązanie chmurowe oparte na API, aby umożliwić firmom wdrożenie SCA zgodnego z PSD2. Usługa mobilna SAP Authentication 365 to kompleksowa usługa, która umożliwia szybkie i bezpieczne wdrożenie usługi wielokanałowego uwierzytelniania dwuskładnikowego (2FA) z uwierzytelnianiem dostosowanym do Twojej firmy cyfrowej.

Pomaga chronić tożsamość i dane klientów korporacyjnych, umożliwiając uwierzytelnianie za pośrednictwem wiadomości SMS, e-mail, powiadomień push lub tokenów TOTP. Interfejs API REST firmy SAP upraszcza generowanie i uwierzytelnianie kodów weryfikacyjnych lub uwierzytelniających oraz zapewnia elastyczność i możliwości umożliwiające wdrożenie strategii SCA zgodnej z PSD2.