Форум вопросов и ответов по директиве PSD2

Узнайте ответы на более чем 40 вопросов по аутентификации, технологии Dynamic Linking, безопасности мобильных приложений и т. д.

Какие штрафные санкции накладываются на платежную систему за несоответствие новому техническому регламенту на ноябрь 2018 г.?

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

Опубликует ли ЕБО руководство по оценке на основе технического регламента по строгой аутентификации клиентов и обеспечению безопасности центров обслуживания — аналогично ЕЦБ в 2014 г.?

У нас нет информации о том, что ЕБО планирует (или не планирует) выпустить аналогичный документ.

Соответствует ли аутентификация через SMS директиве PSD2?

Предполагалось, что технический регламент ЕБО должен быть технологически-нейтральным, чтобы не ограничивать инновации. По этой причине в нем не упоминаются конкретные технологии. Однако некоторые существующие практики больше не соответствуют требованиям к строгой аутентификации клиентов. Мы считаем, что SMS можно рассматривать как "собственность", поскольку их обычно может прочесть только лицо, для которого они предназначены. В этом случае аутентификация через SMS может считаться строгой, поэтому ее можно использовать в решении для подписи транзакций.

Но чтобы соблюсти требования Dynamic Linking, в SMS помимо кода аутентификации необходимо добавлять платежные реквизиты — сумму платежа и информацию о получателе. В требованиях по обеспечению Dynamic Linking также указано, что поставщик услуг должен защищать конфиденциальность и целостность платежных реквизитов. Возможно, подразумевается, что платежные реквизиты необходимо шифровать. Однако в этом случае на SIM-карту или на сам телефон придется установить приложение для дешифровки SMS, а это непрактично.

Наконец, аутентификация через SMS предполагает высокий уровень защиты устройства пользователя, защиту от подмены SIM-карты, перехвата и неправомерного использования SMS. Но на самом деле обеспечить такой уровень защиты в данный момент очень сложно. Уполномоченные инстанции еще не выработали единое мнение насчет того, возможна ли строгая аутентификация через SMS. Разные инстанции высказывают разные мнения на этот счет. Мы внимательно следим за новостями по этой теме. Как только этот вопрос будет решен, мы обновим ответы на часто задаваемые вопросы.

Можно ли рассматривать мобильное устройство и токен как два канала аутентификации — в соответствии Директивой PSD2?

Согласно директиве PSD2, аутентификацию следует выполнять по двум из трех факторов: собственности (чему-то, что есть только у пользователя), информации (чему-то, что знает только пользователь) и характеристике (чему-то, чем является только пользователь).

В каких случаях вы используете код аутентификации? Рассматриваете ли вы его как второй фактор?

Код аутентификации необходимо использовать всегда. Механизм аутентификации должен генерировать его на основе двух из трех возможных факторов аутентификации: собственности (чего-то, что есть только у пользователя), информации (чего-то, что знает только пользователь) и характеристики (чего-то, чем является только пользователь).

Обязательно ли его использовать?

Протокол 3-D Secure действительно позволяет платежным системам обеспечить строгую аутентификацию клиента в случае платежей на основе карт.

Каким из трех компонентов строгой аутентификации клиента является одноразовый пароль, отправляемый в SMS? Это информация или собственность?

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

Уточните, на что распространяется Директива PSD2. Только на онлайн-платежи (через браузер)? Или на что-то еще?

Директива PSD2 распространяется на платежи на сайтах и с мобильных устройств.

Как работает ваш механизм анализа поведения? Это дополнение к SDK DP4APPS?

Аутентификация по поведению от OneSpan — это дополнение к OneSpan Mobile Security Suite. Аутентификация по поведению позволяет не только точно и без проблем подтвердить личность пользователя, но и отслеживать определенное поведение, например атаки ботов. Подробнее см. здесь.

Пользователи OneSpan Mobile Security Suite используют существующее развертывание, просто добавляя в него новые компоненты. Чтобы добиться идеального баланса между безопасностью и удобством, в современную систему безопасности необходимо добавить сразу три перечисленных ниже компонента.

  1. Систему защиты мобильных приложений с функцией сбора данных с клиентского устройства.
  2. Многофакторную биометрическую аутентификацию и защищенный канал связи.
  3. ПО для анализа фрода и рисков, которое будет в реальном времени анализировать пользовательские данные, устройства и поведение, а затем применять соответствующие меры по нескольким каналам. В решении OneSpan есть все эти компоненты.

 

Подробнее о соответствии Директиве PSD2 см. здесь.

Где следует выполнять биометрическую аутентификацию — на стороне сервера или на стороне клиента?

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

Получила ли OneSpan от ЕЦБ официальный сертификат соответствия своих токенов техническому регламенту PSD2?

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

Планируете ли вы снабдить все модели токенов (например, DP310) значком соответствия PSD2?

Пока не планируем. Более того, официальной программы сертификации соответствия PSD2 для инструментов строгой аутентификации пока не существует.

Соответствуют ли банковские терминалы OneSpan техническому регламенту PSD2?

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

Кроме того, плательщика необходимо уведомить о том, какая информация о транзакции будет для этого использоваться. Наконец, на всех этапах аутентификации необходимо защищать конфиденциальность, целостность и подлинность информации о транзакции. Вот что мы можем сказать о банковских терминалах в связи с этими требованиями:

  • Банковский терминал надежно защищает такие факторы аутентификации, как собственность и информация.
  • Банковский терминал позволяет конечному пользователю ввести сумму и информацию о получателе для того, чтобы генерировать уникальный код аутентификации.
  • Пользователь знает, для чего используется банковский терминал. Следовательно, если устройство Digipass с функцией банковского терминала используется в режиме подписи данных о транзакции, это соответствует требованиям к Dynamic Linking.

Dynamic Linking и подпись транзакции — это одно и то же?

Да. Термин "Dynamic Linking" используется в Директиве PSD2 и в техническом регламенте строгой аутентификации клиента.

Значит ли это, что Dynamic Linking обеспечивает OneSpan, а не другая организация, например платежная система?

Строгую аутентификацию клиентов обязана обеспечить платежная система. А OneSpan предоставляет ей необходимые продукты и услуги.

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

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

Как вы соблюдаете требования из статьи 2(2)A, если клиент одновременно оформляет несколько платежей для разных получателей?

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

Есть ли у OneSpan решения, позволяющие генерировать Dynamic Linking, если клиенты не хотят использовать смартфоны?

На сегодняшний день OneSpan предоставляет решения для аутентификации более 2000 банков по всему миру — с разными требованиями, пользователями и стандартами. Таким образом, у OneSpan есть решения на любой вкус. Например, мы предлагаем очень простые, удобные, соответствующие Директиве PSD2 устройства для людей преклонного возраста — с большими экранами, кнопками и даже с поддержкой голосовых команд. Это устройства Digipass 301

Также очень популярны ультрасовременные SWYS-устройства с долговечной резиновой клавиатурой — Digipass 770

Чтобы выполнить аутентификацию с их помощью, клиенту достаточно подтвердить согласие на транзакцию и ввести короткий PIN-код. Исследования, проведенные клиентами OneSpan, показали, что пользователи очень быстро привыкают к устройствах OneSpan, после чего намного реже обращаются в службу поддержки.

Если мы используем 3DS-аутентификацию с помощью SMS, нужно ли добавлять в SMS с одноразовым паролем платежные реквизиты, с помощью которых он сгенерирован (номер счета получателя, сумму платежа и т. д.)?

Мы считаем, что нужно. По крайней мере, именно так мы интерпретируем требования, изложенные в финальной версии технического регламента строгой аутентификации.

Мы используем устройство Digipass 275 с 5 номерами, которое может ответить на запрос для Dynamic Linking. Соответствует ли оно требованиям к Dynamic Linking?

Скорее всего, оно соответствует требованиям, представленным в финальной версии технического регламента.

Соответствует ли OneSpan Go 6 Digipass требованиям технического регламента по технологии Dynamic Linking для крупных платежей?

Токены Go не генерируют коды аутентификации на основе платежных реквизитов (например, суммы платежа). Поэтому их нельзя использовать для технологии Dynamic Linking, необходимой во всех случаях, когда сумма платежа превышает 500 евро.

Как токены одноразовых паролей и другие аппаратные решения обеспечивают по технологии Dynamic Linking в случае единичных транзакций?

Пользователи вводят в аппаратные токены платежные реквизиты, например сумму платежа и номер счета получателя — с клавиатуры токена, через USB-кабель или путем сканирования кода. По этим реквизитам токен вычисляет код аутентификации — в соответствии с требованиями к Dynamic Linking.

Нужно ли показывать платежные данные (сумму и номер счета) на токене? То, что вы видите — это то, что вы подписываете?

Концепция SWYS на аппаратных токенах позволяет обеспечить Dynamic Linking, но есть и другие варианты. Вероятно, эти данные можно просто отобразить в мобильном приложении.

Расскажите подробнее о подписи/авторизации при одновременном оформлении нескольких транзакций. Позволяет ли Dynamic Linking выбрать нескольких получателей и провести сразу несколько транзакций?

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

Нужна ли технология Dynamic Linking при платежах менее 30 евро, если используется решение для мониторинга транзакций?

Нет, если сумма платежа меньше 30 евро, Dynamic Linking не требуется — при условии, что общая сумма или количество предыдущих удаленных платежных онлайн-транзакций, инициированных плательщиком с момента последней строгой аутентификации, не превышает, соответственно, 100 Евро или пять транзакций.

Позволяют ли исключения из технического регламента в некоторых случаях обойтись без строгой аутентификации клиента и ограничиться только Dynamic Linking?

Мы считаем, что да.

Что думает OneSpan о применении технического регламента в корпоративных банковских системах?

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

Что, если у клиента есть список получателей с сертификатами строгой аутентификации, но ему нужно перевести другую сумму?

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

Технический регламент позволяет выполнять аутентификацию по одному фактору только после первой попытки. Двухфакторную аутентификацию следует выполнять каждые 9 дней. Ранее вы рекомендовали поступать иначе. Объясните, почему.

В 10 статье финальной версии технического регламента сказано, что платежные системы также обязаны выполнять строгую аутентификацию плательщиков, которые хотят узнать свой баланс или историю платежей за последние 90 дней в следующих случаях:

  • если пользователь платежной системы получает онлайн доступ к балансу своего счета или истории платежей в первый раз;
     
  • если с момента последней попытки получить доступ к истории платежей и строгой аутентификации клиента прошло 90 дней (подробнее см. в параграфе 1 финальной версии технического регламента).

Можно ли добавлять платежи в "белый" список? Можно ли не использовать Dynamic Linking, если получатель платежа добавлен в белый список?

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

Нужно ли создавать новый пакет OneSpan Mobile App Shielding при каждом обновлении приложения для мобильного банкинга?

Этот вопрос состоит из двух частей:

  • Каждый раз, когда платежная система выпускает мобильное приложение на рынок, к нему необходимо применять технологию шилдирования. К счастью, обертывание шилдирования приложения занимает всего несколько секунд, поэтому оно не помешает платежной системе выпускать обновления в положенные сроки.
     
  • Решение OneSpan Mobile App Shielding регулярно обновляется, поэтому мы рекомендуем платежным системам всегда использовать новейшую версию технологии шилдирования приложений, чтобы обеспечить максимальную защиту.

Защищает ли технология шилдирования мобильные приложения при клонировании?

В OneSpan Mobile Security Suite предусмотрена функция привязки устройств, позволяющая защитить мобильные приложения при клонировании.

Нужно ли шилдировать мобильное приложение при аутентификации через SMS? А через приложение на SIM-карте?

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

Нужно ли принимать дополнительные меры по обеспечению безопасности, если аутентификация выполняется через механизм App2App, а не через push-уведомления?

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

Если транзакция инициирована в приложении для мобильного банкинга, между ним и приложением для аутентификации (на том же устройстве) будет проложен канал связи App2App. Это позволяет автоматически переключаться между этими приложениями, что очень удобно для пользователя.

Если транзакция инициирована в веб-браузере с другого устройства (ПК или планшета), push-уведомление будет отправлено в приложение для аутентификации, установленное на устройстве пользователя. Вместо этого также можно использовать процесс оптического сканирования и подписи — с точки зрения пользователя это практически одно и то же.

Подробнее о решениях Cronto см. здесь: Cronto Sign.

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

Можно ли использовать универсальную платформу Windows (UWP) и планшеты с ОС Windows для строгой аутентификации клиента в сценариях 2АА или 1АА? Будет ли изолированная среда отличаться от изолированной среды для iOS или Android?

Изолированная среда для универсальной платформы Windows (UWP) создается практически так же, как для iOS или Android. Принципы работы UWP во многом схожи с Android и iOS. В Windows 10 Mobile можно запускать только приложения UWP, поэтому изолированная среда в этой ОС так же надежна, как на платформах Android и iOS, чего нельзя сказать о стандартной операционной системе Windows 10, в которой можно запускать как приложения UWP, так и обычные приложения для ОС Windows.

Какие сценарии использования с наибольшей вероятностью будут применяться к транзакциям, инициированным из стороннего приложения?

В сторонних приложениях, скорее всего, будут использованы эти три сценария:

  • Push-уведомление от банка, отправленное финансовой организацией в приложение для аутентификации. Отдельная интеграция между сторонами для этого не требуется.
     
  • Связь App2App между сторонним приложением и приложением для аутентификации, которое предоставляет финансовая организация. Для этого необходимо по минимуму интегрировать службу аутентификации между сторонним поставщиком приложения и финансовой организацией.  
     
  • Мобильная система безопасности, встроенная в стороннее приложение. В этом случае предполагается, что сторонний поставщик приложений использует собственную службу аутентификации, не полагаясь на финансовую организацию.

Во всех трех случаях сторонний поставщик приложений и финансовая организация должны собирать с устройств данные, введенные пользователями, и тщательно анализировать множество приложений, каналов и конечных точек для полной оценки рисков. Мы рекомендуем в этом случае использовать специальное ПО для анализа рисков, например OneSpan Risk Analytics, которое:

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

Если для аутентификации используются два мобильных приложения, нужно ли обоим приложениям использовать ОС для изолированной среды и технологию шилдирования мобильных приложений?

ОС мобильного устройства (например, Android или iOS) создает изолированную среду для всех приложений, которые на нем выполняются. Шилдировать необходимо приложение для аутентификации.

SDK Digipass доступен/совместим с нативным скриптом?

Да.

Расскажите подробнее о безопасной связи с приложениями с помощью OneSpan Mobile Security Suite. Какие технологии делают ее безопасной? Что для этого должно быть на сервере?

Функция безопасной связи в OneSpan Mobile Security Suite позволяет создать безопасный канал связи между приложением и сервером — с защитой конфиденциальности, целостности и подлинности всех платежных реквизитов. OneSpan Mobile Security Suite идет в комплекте с SDK для безопасной связи, которые можно развернуть как на стороне клиента, так и на стороне сервера. С их помощью платежные системы могут без труда создать защищенный канал связи с автоматизированным управлением.

Рекомендуете ли вы использовать алгоритм HMAC, если для аутентификации необходимо использовать аппаратный идентификатор, отпечаток пальца и PIN-код?

В этом случае мы рекомендуем использовать стандартные алгоритмы HMAC, например HMAC-SHA256 или HMAC-SHA3.

Нужно ли шилдировать оба приложения, чтобы соблюсти требования строгой аутентификации в сценарии 2АА? Или достаточно защитить только приложение для аутентификации?

Приложение для аутентификации необходимо шилдировать. Финальная версия технического регламента не требует шилдировать приложение для банкинга, но при желании вы можете это сделать.

Рекомендуете ли вы использовать аутентификацию по поведению?

Да, ведь поведение — это неотъемлемая характеристика пользователя. В комментариях к финальной версии технического регламента строгой аутентификации ЕБО есть информация о том, что это возможно.

Предлагает ли OneSpan решение для аутентификации по "неотъемлемым характеристикам" (биометрии)?

Да, OneSpan Mobile Security Suite поддерживает биометрическую аутентификацию — по отпечаткам пальцев, лицу и поведению пользователя.

Расскажите подробнее об анализе рисков при массовых платежах.

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

Поддерживает ли решение OneSpan для анализа рисков все типы транзакций — через онлайн-банкинг и мобильный банкинг, карты, кассовые аппараты, электронные кошельки и т. д.?

Да, OneSpan Risk Analytics может анализировать транзакции по самым разным каналам.

Решение OneSpan развертывается в облаке? Если да, то в частном или общедоступном?

OneSpan Risk Analytics можно развернуть как в локальной среде, так и в облаке. Облачная версия размещается в среде OneSpan.

Соответствует ли OneSpan Risk Analytics техническому регламенту строгой аутентификации клиента?

Да, OneSpan Risk Analytics может анализировать риски при транзакциях в соответствии с требованиями, изложенными в финальной версии технического регламента.

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

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

Есть ли в директивах или руководствах особые требования к решениям аутентификации 2АА и 1АА в случае потери или кражи физического носителя?

В финальной версии технического регламента сказано, что процедура аутентификации должна включать механизмы отслеживания транзакций, выявляющие попытки использовать незаконно присвоенные учетные данные пользователя для совершения платежей. Это требование распространяется на все решения для аутентификации, а не только на категории 2АА или 1АА.

Связаться с нами

У вас есть другие вопросы по Директиве PSD2? Мы готовы быстро предоставить вам всю необходимую информацию.