Заключительная глава: Строгая аутентификация клиентов (SCA) для PSD2
Опубликовано: 2018-09-05Это третья часть из трех статей, в которых подробно описывается строгая аутентификация клиентов (SCA) PSD2 в ЕС.
Мы добрались до третьего и последнего выпуска этой серии. В первой части мы представили директиву Европейского банковского управления Европейского Союза (или EBA) под названием PSD2 (сокращение от The Second Payment Services Directive) и изложили некоторые руководящие принципы строгой аутентификации клиентов (или SCA). Во второй части были рассмотрены ограничения и правила SCA, которые должны учитывать разработчики, включая коды аутентификации, динамическое связывание транзакций и независимость от каналов.
В этом посте мы опишем варианты реализации SCA, которые должны удовлетворять требованиям, изложенным в PSD2 RTS (нормативный технический стандарт), а также несколько хороших мест, где можно найти дополнительную информацию.
Прежде чем мы рассмотрим некоторые варианты реализации SCA, мы также должны указать, что есть некоторые исключения из строгой аутентификации и динамического связывания .
В часто задаваемых вопросах пресс-релиза PSD2 они отмечают: «[исключения сделаны] для того, чтобы не нарушать методы работы потребителей, продавцов и поставщиков платежных услуг. Это также связано с тем, что могут существовать альтернативные механизмы аутентификации, которые одинаково безопасны и надежны. Однако «поставщики платежных услуг, которые хотят быть освобождены от SCA, должны сначала применить механизмы мониторинга транзакций, чтобы оценить, низок ли риск мошенничества». Конкретные исключения изложены в главе III RTS PSD2.
Две области, в которых требуется строгая аутентификация клиентов в PSD2
- Доступ к учетной записи — это доступ к платежным счетам через любое устройство: настольный компьютер, ноутбук, планшет или мобильный телефон.
- Платежи — это фактическая аутентификация платежа, включая динамическую привязку платежной информации к методу аутентификации.
В современном многоканальном мире с множеством устройств существует множество методов банковских/платежных приложений для выполнения аутентификации, от простого 2FA на основе SMS до более сложного (и безопасного) универсального 2- го фактора (U2F) от Fido. Альянс вместе со всем, что между ними.
Сегодня у нас обычно есть четыре основные конфигурации:
- Два устройства – на одном запущено банковское/торговое приложение; другой, обеспечивающий аутентификацию. Это будет включать в себя аппаратные токены, а также устройства U2F в качестве устройств аутентификации, но также будет включать мобильное устройство и ноутбук с ноутбуком, на котором запущено банковское/торговое приложение, и мобильное устройство, обеспечивающее аутентификацию (даже внеполосную аутентификацию).
- Два приложения, одно устройство — на одном устройстве, как правило, на мобильном телефоне, у нас было бы приложение для банка/торговца и приложение для аутентификации. Приложение для аутентификации может включать решение с программным токеном, такое как Google Authenticator, или специальное приложение для аутентификации, которое будет интегрироваться с банком/продавцом для передачи, например, динамически связанной информации о покупке в приложение для аутентификации.
- Одно приложение, одно устройство — примером может служить мобильное банковское приложение, которое также обеспечивает возможность аутентификации в этом приложении.
- Внеполосная аутентификация или OOB-аутентификация включает в себя отправку SMS на номер мобильного телефона, защищенную SIM-картой. В этом случае мобильное устройство, доступ к которому осуществляется через внеполосный канал, такой как SMS (или даже RCS, если он поддерживается), будет вторым фактором (владением).
Учитывая все эти варианты, каковы были бы наилучшие варианты и методы для поддержки SCA PSD2 и обеспечения соответствия требованиям?
Опция Out-of-Band (OOB) — это самый простой и наиболее известный пользователям метод. Это полностью соответствует правилам доступа к учетной записи и должно быть опцией для платежей, если информация о платеже включена в SMS. Он также отвечает требованию независимости канала.
Конечно, в наши дни есть некоторые проблемы с безопасностью SMS; однако многие из них несколько преувеличены в прессе (например, подмена SIM-карт, перехват SMS). Тем не менее, есть лучшие и более безопасные методы. Если вы используете SMS в качестве канала OOB для двухфакторной аутентификации, рассмотрите возможность добавления дополнительного фактора знаний для дополнительной защиты учетной записи или платежа. Это обеспечит дополнительную защиту от определенных сценариев подмены SIM-карты или перехвата SMS, если они произойдут.
Одна из проблем с вариантом аутентификации с несколькими устройствами (2-устройствами) с использованием различных аппаратных устройств для аутентификации для платежей заключается в том, что сложно включить динамическую привязку информации о платеже/продавце обратно к этому устройству аутентификации. Хотя многие из них достаточно безопасны, например устройства U2F, сложно включить динамическую привязку информации о покупке/платежах.
Одним из полезных методов было бы использование решения для аутентификации, которое по-прежнему создает стандартный PIN-код в облаке, но использует зашифрованную информацию, отправляемую в специализированное приложение для аутентификации. Банковское/торговое приложение также может включать платежную информацию вместе с кодом, который будет отправлен в приложение аутентификации.
Приложение для аутентификации предоставит информацию пользователю, а затем ответит «Принять» или «Отклонить». Приложение для аутентификации может быть частью стратегии двух устройств, а также стратегии двух приложений (одно устройство). Приложение не будет зависеть от телефонных номеров (например, OOB) и, следовательно, будет устойчиво к подмене SIM-карты или захвату устройства. Кроме того, устройство должно находиться в физическом владении владельца учетной записи вместе с информацией, основанной на знаниях владельца учетной записи.
К счастью, поставщикам платежей из ЕС доступно множество вариантов, которым в ближайшие месяцы потребуется внедрить PSD2 SCA. Каждый из них будет иметь конкретные варианты использования, которые следует тщательно изучить, чтобы определить, следует ли применять ресурсы SCA. Вот несколько советов:
- Изучите каждый вариант использования
- Узнайте, могут ли применяться исключения SCA
- Определите, связан ли вариант использования с доступом к учетной записи или платежами
- Для платежей определите, как вы будете предоставлять информацию о платеже и продавце пользователю (динамическая привязка)
- Для доступа к учетной записи мы рекомендуем всегда применять двухфакторную аутентификацию для входа в систему — это просто более безопасно.
Мы ожидаем, что для большинства рынков ЕС наиболее распространенным способом онлайн-покупок и платежей будет мобильное устройство. Следовательно, это означает, что устройство будет использоваться как основное устройство для покупок/платежей, а также для аутентификации. Не всегда ожидайте, что пользователи будут использовать настольные компьютеры или ноутбуки. Использование мобильных устройств (включая планшеты) будет только увеличиваться в качестве основных устройств.
PSD2 SCA представляет собой сложный набор правил, но при наличии здравого смысла и понимания современных проблем и вариантов аутентификации его можно реализовать в соответствии с этими правилами, а также защитить все вовлеченные стороны. В последние месяцы некоторые требования SCA и некоторые ограничения, которые они налагают, подвергались критике. На самом деле, в ближайшие месяцы и годы могут появиться дополнительные правила (PSD3?).
Не бойтесь внедрять SCA, если вы занимаетесь онлайн-платежами. Не ждите до последней минуты. Потратьте время, чтобы прочитать требования, изучить их, а затем принимать решения. Существует множество вариантов, и мы надеемся, что эта серия из трех частей помогла вам разобраться с различными вариантами и элементами PSD2 SCA.