PSD2: Silne uwierzytelnianie klienta w UE

Jest to drugi z trzyczęściowej serii postów opisujących PSD2: Silne uwierzytelnianie klienta w UE (SCA).

W pierwszej części tej trzyczęściowej serii wprowadziliśmy dyrektywę Europejskiego Urzędu Nadzoru Bankowego (lub EBA) Unii Europejskiej o nazwie PSD2 (skrót od The Second Payment Services Directive) i przedstawiliśmy niektóre z przewodnich zasad silnego uwierzytelniania klienta (lub SCA). .

Odnosząc się do 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). Jak wspomniano w Części 1, Regulacyjny Standard Techniczny (RTS) czyni silne uwierzytelnianie klienta (SCA) podstawą dostępu do konta płatniczego, a także dokonywania płatności online”.

W tym poście omówimy ograniczenia i organy regulacyjne SCA, które muszą wziąć pod uwagę realizatorzy. Najpierw spójrzmy na generowane kody uwierzytelniające. Pamiętaj, że jest to zasadniczo uwierzytelnianie dwuskładnikowe lub 2FA.

RTS określa następujące warunki dla kodów uwierzytelniających:

• Z ujawnienia kodu uwierzytelniającego nie można uzyskać żadnych informacji dotyczących wiedzy, posiadania i dziedziczenia. Oznacza to, że jeśli znasz kod uwierzytelniający, nie ma możliwości uzyskania innego elementu wiedzy (np. identyfikatora użytkownika), który użytkownik posiada (powiedzmy telefon komórkowy – co oznacza, że ​​nie możesz uzyskać numeru telefonu komórkowego) lub dziedziczenie – aspekty dotyczące samych użytkowników, takie jak biometria.
• Nie jest możliwe wygenerowanie nowego kodu uwierzytelniającego na podstawie znajomości innego wygenerowanego wcześniej kodu uwierzytelniającego . Dla tego warunku, przy danym kodzie uwierzytelniającym, nie ma możliwości wygenerowania nowego kodu uwierzytelniającego przez odwołanie się do jednego lub wielu poprzednich kodów uwierzytelniających.
• Kod uwierzytelniający nie może być sfałszowany . Realizator musi stworzyć kody uwierzytelniające, aby sfałszowane lub fałszywe kody nie mogły zostać pomyślnie zweryfikowane.
• Nie należy podejmować więcej niż 5 nieudanych prób uwierzytelnienia w czasie życia kodu. Każdy wygenerowany kod będzie miał czas wygaśnięcia lub „czas życia”. Ten zegar uruchamia się natychmiast po wygenerowaniu kodu i obejmuje czas dostawy. Dobrą zasadą jest to, że kod powinien wygasnąć w ciągu 15 minut lub mniej. Niektórym organizacjom zajmuje to do 30 minut lub 1 godziny, ale może to trwać zbyt długo. Jeśli użytkownik próbuje uwierzytelnić się kodem i 5 razy się nie powiedzie, należy wysłać nowy kod. Zapobiega to wszelkim typom brutalnych prób rozszyfrowania kodu.
• Maksymalny czas bezczynności płatnika lub użytkownika po uwierzytelnieniu dostępu do jego rachunku płatniczego w trybie online nie może przekroczyć 5 minut . Jest to standardowy licznik czasu braku aktywności, który, mimo że jest oddzielony od kodu uwierzytelniającego, jest licznikiem czasu, który uruchamia się po pomyślnym uwierzytelnieniu użytkownika i nie wykonuje żadnej czynności.

To wszystko są stosunkowo standardowe warunki generowania/walidacji kodu uwierzytelniającego używanego w sytuacjach 2FA.

Przyjrzyjmy się teraz wymaganiu RTS o nazwie Dynamiczne łączenie transakcji. Elektroniczne transakcje zdalne (np. dokonywane przez Internet, niezależnie od tego, czy urządzenie było komputerem stacjonarnym, czy mobilnym) powinny zawierać elementy, które „dynamicznie łączą transakcję z określoną kwotą (płatności) i konkretnym odbiorcą.

Ten wymóg SCA wskazuje, że kwota płatności transakcji, wraz z którą dokonywana jest płatność, powinna zostać zwrócona użytkownikowi w momencie transakcji 2FA.

Na przykład wiadomość SMS otrzymana przez użytkownika zweryfikuje kwotę zakupu i sprzedawcę, wraz z kodem zabezpieczającym (uwierzytelniającym) i informacją o wygaśnięciu tego kodu. Należy zauważyć, że kwota zakupu i sprzedawca nie są szyfrowane.

Alternatywą byłoby umieszczenie adresu URL wraz z kodem zabezpieczającym w wiadomości SMS. Adres URL chciałby uzyskać połączone, zaszyfrowane informacje o transakcji – dostępne za pośrednictwem czegoś, co użytkownik zna, a także kodu zabezpieczającego (otrzymanego na czymś, co użytkownik posiada).

Kody uwierzytelniające generowane przez aplikacje innych firm zgodne z TOTP, takie jak Google Authenticator i wiele innych, są całkowicie oddzielone od informacji o płatnościach/sprzedawcy. Nieco kłopotliwa jest możliwość dynamicznego łączenia tych kodów z transakcją.

Ponadto większość z tych bezpłatnych aplikacji może nie zawierać odpowiednich środków do obsługi dynamicznego łączenia danych transakcji i zapewniania, że ​​te aplikacje zawierają środki zaradcze w celu zakłócenia klonowania aplikacji, a także wykrywania jailbreak i rootowania. To powiedziawszy, istnieją specjalne zestawy SDK i interfejsy API, które mogą zapewnić te środki zaradcze zgodnym aplikacjom mobilnym.

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

Wymóg niezależności kanału głosowego stanowi, że „dostawcy usług płatniczych przyjmują środki bezpieczeństwa, w przypadku gdy 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 wielozadaniowego urządzenie celowe jest zagrożone.”

Wielozadaniowym urządzeniem może być urządzenie mobilne, tablet lub laptop. W rzeczywistości prawdopodobnie zaistnieją scenariusze, w których aplikacja bankowa/płatnicza i aplikacja uwierzytelniająca znajdują się na tym samym urządzeniu. W kilku przypadkach mogą być częścią tej samej aplikacji. Alternatywnie aplikacja do płatności może polegać na kanale uwierzytelniania poza pasmem (takim jak SMS).

Kanały odnoszą się do sposobów interakcji z użytkownikiem. Kanał płatności online użytkownika (lub dostęp do rachunku płatniczego) i kanał używany do uwierzytelniania nie mogą być takie same. Jeśli chodzi o dostępne kombinacje urządzeń, które są obecnie dostępne na rynku, niezależność kanału wiąże się z szeregiem problemów. Uwierzytelnianie pozapasmowe za pośrednictwem wiadomości SMS jest szeroko stosowane, łatwe w użyciu i dość popularne wśród konsumentów; jednak ma pewne dostrzegane problemy z bezpieczeństwem.

Oprócz rozwiązań pozapasmowych, takich jak SMS, innym dobrym i praktycznym rozwiązaniem niezależnym od kanału byłoby wykorzystanie wiadomości push za pośrednictwem oddzielnego rozwiązania do uwierzytelniania w chmurze do aplikacji do uwierzytelniania mobilnego lub nawet aplikacji bankowej/płatniczej/handlowca z informacjami o płatnościach jako jak również unikalny kod.

Inną możliwą metodą spełnienia tych wymagań jest oddzielna aplikacja uwierzytelniająca, która zawiera odpowiednie środki zaradcze i odbiera dynamicznie powiązane informacje za pośrednictwem zaszyfrowanego, niezależnego kanału.

W trzeciej części tej trzyczęściowej serii omówimy niektóre opcje implementacji SCA, które powinny spełniać wymagania określone w RTS, a także kilka miejsc, w których można znaleźć więcej informacji.

Proszę rozważyć śledzenie mnie na Twitterze: @wdudley2009

Dowiedz się, jaki wpływ może mieć obecny kryzys zdrowotny na strategię biznesową, transformację cyfrową i przyszłość handlu elektronicznego TUTAJ.