PSD2: Надежная аутентификация клиентов в ЕС

Это вторая из трех частей серии постов, подробно описывающих PSD2: строгая аутентификация клиентов в ЕС (SCA).

В первой части этой серии, состоящей из трех частей, мы представили директиву Европейского банковского управления Европейского Союза (или EBA) под названием PSD2 (сокращение от The Second Payment Services Directive) и изложили некоторые руководящие принципы строгой аутентификации клиентов (или SCA). .

Ссылаясь на SCA, EBA отмечает: «Благодаря PSD2 потребители будут лучше защищены при совершении электронных платежей или транзакций (например, при использовании онлайн-банкинга или покупок в Интернете). Как отмечалось в Части 1, Регулирующий технический стандарт (RTS) делает строгую аутентификацию клиента (SCA) основой для доступа к платежному счету, а также для совершения платежей в Интернете».

В этом посте мы рассмотрим ограничения и регуляторы SCA, которые должны учитывать разработчики. Во-первых, давайте посмотрим на сгенерированные коды аутентификации. Помните, что по сути это двухфакторная аутентификация или 2FA.

RTS описывает следующие условия для кодов аутентификации:

• Никакая информация о знании, владении и наследовании не может быть получена из раскрытия кода аутентификации. Это означает, что если вы знаете код аутентификации, нет никакого способа получить какой-либо другой элемент знаний (например, идентификатор пользователя), который находится в распоряжении пользователя (скажем, мобильный телефон — это означает, что вы не можете получить номер мобильного телефона) или наследование — аспекты самих пользователей, такие как биометрия.
• Невозможно сгенерировать новый код аутентификации, основываясь на информации о каком-либо другом ранее сгенерированном коде аутентификации . Для этого условия при наличии любого кода аутентификации невозможно сгенерировать новый код аутентификации, ссылаясь на один или несколько предыдущих кодов аутентификации.
• Код аутентификации нельзя подделать . Разработчик должен создать коды аутентификации, чтобы поддельные или поддельные коды не могли быть успешно проверены.
• За время жизни кода должно быть предпринято не более 5 неудачных попыток аутентификации. Каждый сгенерированный код будет иметь срок действия или «время жизни». Этот таймер запускается сразу после генерации кода и включает время доставки. Хорошее эмпирическое правило заключается в том, что код должен истечь через 15 минут или меньше. В некоторых организациях для этого требуется 30 минут или 1 час, но это может быть слишком долго. Если пользователь пытается аутентифицироваться с помощью кода и терпит неудачу 5 раз, необходимо отправить новый код. Это предотвращает любые попытки грубой силы вычислить код.
• Максимальное время бездействия плательщика или пользователя после аутентификации для доступа к его платежному счету в Интернете не должно превышать 5 минут . Это стандартный таймер бездействия, и хотя он отделен от кода аутентификации, это таймер, который запускается после успешной аутентификации пользователя и не выполняет никаких действий.

Все это относительно стандартные условия для генерации/проверки кода аутентификации, используемого в ситуациях 2FA.

Теперь давайте взглянем на требование RTS под названием Dynamic Linking of the Transactions. Электронные удаленные транзакции (например, совершаемые через Интернет, независимо от того, было ли это настольное устройство или мобильное устройство) должны включать элементы, которые «динамически связывают транзакцию с конкретной суммой (платежа) и конкретным получателем платежа.

Это требование SCA указывает, что сумма платежа по транзакции вместе с тем, кому производится платеж, должна быть возвращена пользователю во время транзакции 2FA.

Например, SMS, полученное пользователем, будет проверять сумму покупки и продавца, а также код безопасности (аутентификации) и информацию об истечении срока действия этого кода. Следует отметить, что сумма покупки и продавец не зашифрованы.

Альтернативой может быть включение URL-адреса вместе с кодом безопасности в SMS-сообщение. URL-адрес относится к связанной зашифрованной информации о транзакции, доступной через что-то известное пользователю, а также через код безопасности (полученный на чем-то, что есть у пользователя).

Коды аутентификации, сгенерированные сторонними приложениями, совместимыми с TOTP, такими как Google Authenticator и многими другими, полностью отделены от информации о платеже/продавце. Возможность динамически связать эти коды с транзакцией несколько проблематична.

Кроме того, большинство этих бесплатных приложений могут не содержать соответствующих мер для поддержки динамического связывания данных транзакций и обеспечения того, чтобы эти приложения содержали меры противодействия клонированию приложений, а также обнаружению джейлбрейка и рутирования. Тем не менее, есть некоторые специальные SDK и API, которые могут обеспечить эти контрмеры для совместимых мобильных приложений.

Это означает, что код аутентификации, сгенерированный сторонним TOTP-совместимым приложением, таким как Google Authenticator, генерируется отдельно от информации о платеже/продавце и, следовательно, не может быть динамически связан.

Требование о независимости канала гласит, что «поставщики платежных услуг должны принимать меры безопасности, когда любой из элементов строгой аутентификации клиента или сам код аутентификации используется через многоцелевое устройство, чтобы снизить риск, который может возникнуть в результате такой многоцелевой аутентификации». целевое устройство скомпрометировано».

Многоцелевое устройство может быть мобильным устройством, планшетом или ноутбуком. На самом деле, вероятно, будут сценарии, в которых приложение для банковских операций/платежей и приложение для аутентификации находятся на одном устройстве. В некоторых случаях они могут быть частью одного и того же приложения. В качестве альтернативы платежное приложение может полагаться на внешний канал аутентификации (например, SMS).

Каналы относятся к средствам взаимодействия с пользователем. Канал для онлайн-платежей пользователя (или доступа к платежному аккаунту) и канал, используемый для аутентификации, не должны совпадать. С точки зрения доступных комбинаций устройств, представленных сегодня на рынке, независимость канала вызывает ряд проблем. Внеполосная аутентификация с помощью SMS широко распространена, проста в использовании и довольно популярна среди потребителей; однако у него есть некоторые предполагаемые проблемы с безопасностью.

Помимо внеполосных решений, таких как SMS, еще одним хорошим независимым от канала и работоспособным решением будет использование push-сообщений через отдельное решение облачной аутентификации для мобильного приложения аутентификации или даже банковского/платежного/торгового приложения с платежной информацией как а также уникальный код.

Отдельное приложение для проверки подлинности, которое включает в себя соответствующие меры противодействия, получая динамически связанную информацию через зашифрованный независимый канал, является еще одним возможным способом удовлетворения этих требований.

В третьей части этой серии из трех частей мы расскажем о некоторых вариантах реализации SCA, которые должны удовлетворять требованиям, изложенным в RTS, а также о некоторых местах, где можно найти дополнительную информацию.

Пожалуйста, подпишитесь на меня в Твиттере: @wdudley2009

Узнайте, какое влияние нынешний кризис в области здравоохранения может оказать на бизнес-стратегию, цифровую трансформацию и будущее электронной коммерции. ЗДЕСЬ.