Что такое 3ds аутентификация

3-D Secure (3DS): как работает механизм и почему его использование является важным при приеме платежей через вебсайт?

Сегодняшнюю серию блога о приеме платежей через вебсайт команда Finance Business Service хочет посвятить одному из важных аспектов процесса безопасного эквайринга платежных карт – 3-D Secure. Мы глубоко убеждены, что каждый из нас, кто хотя бы раз в своей жизни совершал оплату товаров и услуг в сети Интернет, уже заочно знаком с этим механизмом. Тем не менее, для лучшего понимая схемы его работы и необходимости практического использования, вашему вниманию предлагается следующий материал. Он будет полезен не только для держателей банковских карт (покупателей), но и для владельцев онлайн-бизнеса.

Что такое 3-D Secure?

3-D Secure (Three-Domain Secure) – это протокол защиты, используемый для авторизации платёжного средства (банковской карты) при совершении CNP-оплаты (Card Not Present Payment) за товары и услуги. Впервые данный механизм был задействован оператором платёжных карт Visa, вследствие чего появилась система безопасности Verified by Visa. Чуть позже этому примеру последовал оператор MasterCard и внедрил свой собственный протокол MasterCard Secure Code. Для того, чтобы понять, гарантирует ли тот или иной вебсайт дополнительный уровень защиты интернет-платежей, необходимо обратить внимание на наличие специальных логотипов операторов Visa и MasterCard на его страницах.

Поскольку технология 3-D Secure является технологией повышенной безопасности, она создает ещё одну ступень аутентификации пользователей для подтверждения онлайн-платежей, осуществляемых при помощи платёжных карт. В свою очередь, это позволяет бизнесу (к примеру, интернет-магазину) и его банку-эквайеру убедиться в том, что операции действительно проводятся держателями карт, а не мошенниками.

Схема работы 3-D Secure

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

Стоит отметить, что 3-D Secure авторизация проходит по трём доменам:

Отсюда, собственно говоря, и возникло название Three-Domain Secure. Вся передаваемая информация по платежу сохраняется на домене банка-эмитента, а интернет-магазин не имеет к ней никакого доступа. Но интернет-магазин может хранить часть информации по реквизитам банковской карты, если покупатель даёт своё согласие. Обычно это происходит после нажатия кнопки «Запомнить карту» на вебсайте для ускоренного проведения транзакций в дальнейшем.

Необходимость практического использования 3-D Secure

Несмотря на очевидное преимущество 3-D Secure, не все интернет-торговцы и банки поддерживают данную технологию, так как она не является обязательной. Результаты исследований, проводимых в США, показывают, что ввиду применения 3-D Secure аутентификации, количество «брошенных корзин» в онлайн-магазинах существенно возрастает. Это останавливает мошенников на пути осуществления fraud-платежей. Тем не менее очень часто покупатели критикуют рассматриваемый механизм безопасности из-за неудобства и необходимости заполнения дополнительной формы с кодом авторизации.

По нашему мнению, в использовании 3-D Secure видится реальная практическая необходимость, поскольку пароль из SMS-оповещения является своеобразной гарантией надлежащего владения банковской картой. Кроме этого, поддержка стандарта 3-D Secure продавцом (онлайн-магазином) нивелирует его ответственность в случае попытки проведения несанкционированного платежа. Таким образом бизнес перекладывает бремя ответственности на банк-эмитент, который выпустил ту или иную платёжную карту.

Тем не менее механизм 3-D Secure постепенно устаревает. Недобросовестные покупатели (мошенники) приспособились перехватывать SMS-оповещения банков, тем самым получая доступ к чужим кодам аутентификации. В свою очередь, это наталкивает на мысль о том, что существующие протоколы безопасности требуют модернизации.

Источник

Что такое 3-D Secure и как она защищает твою банковскую карту

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

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

Самое время вспомнить о проверенном временем способе защиты.

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

Как это работает

Изначально технология 3-D Secure была разработана для платежной системы Visa. Позже подобным протоколом обзавелись системы Masterсard, JCB International, AmEx, «Мир» (НСПК) и другие.

Сейчас практически все банки поддерживают 3-D Secure, но не всегда активируют защиту для клиентов по умолчанию.

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

Реже вместо СМС могут использоваться постоянные или одноразовые коды, которые известны лишь держателю карты.

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

Преимущества и недостатки

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

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

3-D Secure снижает оперативность покупателя. СМС с паролем приходят не так быстро, как хотелось бы. Оператор может и вовсе «потерять» нужное сообщение, а если находишься в зоне неуверенного приема, проклинаешь эту защиту через пять минут.

Как еще можно защититься

Система 3-D Secure не гарантирует 100% защиту средств на карте. Для большей надежности следует придерживаться определенных правил:

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

Источник

3D Secure, или что скрывают механизмы безопасности онлайн-платежей

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

Один из протоколов, используемых для увеличения безопасности онлайн-платежей — 3D Secure. Это протокол, который был разработан на основе XML в качестве дополнительного уровня безопасности платежей, проводящихся без физического участия карты (card not present payment). VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.

Почему протокол 3D Secure называется именно так?

Полное название этого протокола — Three Domain Secure.
Первый домен — домен эмитента — это банк, выпустивший используемую карту.
Второй домен — домен эквайера — это банк и продавец, которому выплачиваются деньги.
Третий домен — домен совместимости (interoperability domain) — инфраструктура, используемая при оплате картой (кредитной, дебетовой, предоплаченной или другими типами платежных карт) для поддержки протокола 3D Secure. Он включает в себя Интернет, подключаемый модуль продавца (merchant plug-in), сервер контроля доступа (access control server) и других поставщиков программного обеспечения.

Зачем это нужно?

3D Secure обеспечивает новый уровень безопасности путем предоставления дополнительной информации.
Еще одним важным моментом является «перенос ответственности». Это означает, что в случае мошенничества вся ответственность ложится на банк-эмитент. Этот момент является очень важным для продавца (мерчанта), т.к. до появления 3D Secure урегулированием спорных вопросов приходилось заниматься мерчанту.

Также не стоит забывать о двух важных психологических аспектах: повышении доверия к онлайн-платежам и увеличении конверсии.
Конверсия может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.

Версии протокола 3D Secure

В настоящее время большинство платежных сервисов используют версию 1.0.2 при проведении онлайн CNP-платежей, запрашивающих OTP-код.
Версия 1.0.2 была создана в 2001 году и в ней есть некоторые проблемы.

На данный момент актуальной версией является v2.2, и EMV планирует, что к концу 2020-го года она будет использоваться везде.

Как это устроено?

Это основная схема, необходимая для понимания всего процесса платежа с использованием механизма 3DS.

На этом рисунке мы видим все три домена, используемые в протоколе, а также последовательность сообщений между всеми участниками платежной операции.

Как это работает?

Главное, что необходимо понять, — это то, что при использовании своей карты (виртуальной или реальной) для онлайн-оплаты, вы сталкиваетесь именно с протоколом 3DS. Поэтому сейчас мы проиллюстрируем все этапы совершения онлайн-платежа.

1 — Покупатель уже добавил все необходимые ему товары в корзину и нажал кнопку «Оплатить». В этот момент он попадает на страницу MPI-сервиса, где вводит данные своей карты.

После нажатия кнопки оплаты продавец (MPI) инициализирует старт платежного потока и, согласно протоколу, отправляет CRReq-запрос (Card Range Request). Данный запрос необходим, чтобы найти банк-эмитент вашей карты и получить CRR из домена взаимодействия. Этот запрос нас мало интересует.

После этого MPI отправляет VeReq (Verification Request). Этот запрос отправляется банку-эмитенту для проверки того, что 3DS для данной карты включен и карту можно использовать для оплаты.

VeRes (Verification Response) содержит дополнительную информацию для следующего этапа платежа.

Клиенты не могут видеть эти два типа сообщений.

2 — MPI создает PaReq (Payment Request) — запрос на оплату. Этот запрос отправляется через редирект в браузере клиента.

Итогом отправки PaReq становится отображение запроса на ввод OTP-кода.

3 — Клиент вводит OTP-код и возвращается на сайт продавца. Опять же в процессе этого через редирект от банка-эмитента к MPI передается PaRes (Payment Response), который содержит информацию о статусе проверки.

А поподробнее?

CRReq/CRRes для нас не очень важны. А вот VeReq/VeRes рассмотреть нужно.

В VeReq самым важным параметром является идентификатор сообщения, информация о продавце и PAN карты.

VeRes возвращает message id, который необходим, чтобы сопоставить запрос с этим ответом. А status enrolled показывает, что карта поддерживается.
Однако наиболее важным параметром в данном сообщении является URL-адрес. Этот параметр указывает, где находится ACS сервер эквайера и куда нужно отправить PaReq.

Pareq

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

Платежный запрос, содержащий PaReq (метод POST), имеет три параметра:
1) MD — данные продавца. Он нужен MPI, чтобы сопоставить PaReq и PaRes одной транзакции;
2) PaReq — параметр этого платежного запроса. Он содержит всю важную информацию о платеже;
3) TermUrl — URL-адрес, на который клиент будет возвращен в конце процесса аутентификации 3D Secure.

Параметры TermURL и MD всегда отражаются в ответе на данный запрос. Поэтому могут встречаться имплементации ACS, уязвимые к атакам типа reflected XSS. В процессе аудита различных систем такие сервера были найдены.

Важный момент №1: ACS сервера обрабатывают все входящие PaReq!

Что входит в параметр PaReq?
Вы можете получить его значение, раскодировав PaReq. Это сделать достаточно легко, потому что PaReq — это Xml-> zlib-> base64-> urlencode. Для упрощения работы с этими запросами был написан плагин для burp.

Теперь мы видим, что из себя на самом деле представляет PaReq, а именно сообщение формата xml. Это сообщение содержит информацию о сумме платежа (purchAmount, amount и currency), некоторую информацию о продавце и MessageId (из VeReq).

При отправке правильно сформированного PaReq (в большинстве случаев вам не нужен полный набор запросов на оплату — требуется отправить лишь PaReq, содержащий параметры правильного типа и длины), мы получим PaRes — ответ на платеж, подобный следующему:

Первая мысль, которая может прийти в голову веб-исследователю, который видит XML-запрос — это попробовать выполнить XXE. И это правильный путь!

Но для начала посмотрим на то, что случится, если отправить некорректно сформированный PaReq. Мы получим ошибку! Вот несколько примеров таких ошибок:

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

Раскрутим XXE

Рассмотрим следующий пример:

acqBIN, merID, xid, date, purchAmount и currency отражаются в PaRes. Однако во всех реализациях ACS, которые мы нашли, удалось использовать только merID. Остальные параметры проверяются на соответствие типам данных.

Еще один интересный параметр (и наиболее полезный для атаки) — это URL. Этот параметр не отражается, но и не проверяется. Поэтому его можно использовать для эксплуатации XXE.

Вернемся к нашему примеру. В одной из реализаций ACS мы обнаружили, что можем читать короткие файлы, а также получать ответ в PaRes error через параметр merID. Таким образом, используя PaReq из примера выше, мы получали следующий ответ:

Тем не менее в большинстве случаев оставалось только использовать параметр URL для получения DNS или HTTP-запроса к нашему сервису. Другой вектор — это выполнить DOS через XXE-атаку «billion laughs» (проверялось на тестовом сервере).

Где это можно найти?

В ходе нашего исследования мы обнаружили несколько распространенных URL-адресов:

И распространенные имена поддоменов:

Впрочем, иногда вы можете найти и другие интересные пути.
Если вы хотите найти что-то новое, используйте proxy interceptor и записывайте процесс совершения платежей для интересующей вас платежной системы.

3D Secure v 2. *

Как мы писали ранее, в 3DS v1.0 есть некоторые проблемы.

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

Для этого в 3DS 2.0 предусмотрели 3DS SDK.

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

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

Интересный факт про v1.0. Люди некоторых стран не доверяли этому протоколу, потому что видели редирект и думали, что это мошенничество!

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

Как работает 3D Secure v2?

Начало потока платежей аналогично предыдущей версии. Клиент должен указать данные своей карты.

Первый и самый важный момент — это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.

Особенности работы v2

Если вы посмотрите на схему потока платежей, вы увидите, что она похожа на предыдущую, но во 2-й версии больше этапов. Это происходит за счет добавления дополнительных аутентификационных запросов и механизма Risck Engine, который может совершать как один дополнительный запрос (при платеже через браузер), так и множество (используется 3DS SDK).

Условно, 2-ю версию можно разделить на два блока. Красный, где пользователь непосредственно влияет на передаваемую информацию, и желтый, где система сама собирает и передает информацию о пользователе.

А поподробнее?

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

Это сообщение необходимо для работы системы управления рисками и упрощения покупок.
Если этой информации оказалось недостаточно, Risk Engine сперва попытается получить дополнительную информацию, и именно в этот момент клиент может получить OTP-запрос.

Что контролирует пользователь?

CReq (base64url json) — challenge request — сообщение, отправляемое браузером пользователя, в случае если ARes вернет сообщение о необходимости провести Challenge Flow.

Если платежный процесс использует 3D Secure SDK, это сообщение будет зашифровано (JWE).

В CReq вы можете увидеть следующие поля:

К сожалению, нам пока не удалось провести достаточно подробное исследование 2-й версии протокола 3DS, поэтому сложно сказать, какие уязвимости встречаются чаще. Вы можете стать первым, кто опубликует исследование на данную тему.

Подведем итоги

Проблемы (найденные и возможные)

На что смотреть в v1

На что смотреть в v2

Тем, кто подумывает обратить свой взгляд на платежные системы, я бы посоветовал остановиться еще и на сервисах, предоставляющих 3DS как SaaS. Там может оказаться еще достаточно много вещей, которые помогут вам понять, как устроен мир онлайн-платежей.

Источник

Почему появляется ошибка оплаты после 3DS-аутентификации?

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

Интернет-магазин не получает конфиденциальную информацию о банковской карте, все платежи проходят безопасно. Однако в некоторых случаях возникают сбои. Держатели пластиковых карт видят ошибки оплаты при проведении 3DS-аутентификации.

Код подтверждения операции не пришел

Банковская система в автоматическом режиме направляет на номер телефона держателя пластиковой карты короткий код или одноразовый пароль. Совершить покупку не удается, если входящая смс от банка не пришла. Решить проблему можно одним из способов:

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

Авторизация с ошибкой

Ошибка авторизации 3D-Secure появляется в следующих случаях:

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

Ошибка 3DS-аутентификации

Если платежная операция не прошла 3DS-аутентификацию, виной всему следующие обстоятельства:

Наиболее простой способ разобраться в ошибках при проведении 3DS-аутентификации – позвонить на горячую линию банка. Специалист службы поддержки поможет оперативно разобраться с причинами сбоя в конкретном случае.

Источник

EMV 3-D Secure, или кто украл SMS с одноразовым паролем. Часть 2

В прошлой статье мы рассказали о том, как появился первый протокол надежной аутентификации для платежей по пластиковым картам 3-D Secure 1.0.2, какие задачи он решает и какими недостатками обладает. Теперь мы хотели бы рассказать о будущем технологии 3-D Secure, и почему не стоит переживать, если перестала приходить SMS с одноразовым паролем.

Рождение EMV 3-D Secure

К середине 2010-х моральное и техническое устаревание 3DS 1.0.2 подтолкнуло консорциум EMVCo (организация, занимающаяся разработкой стандартов в сфере платежных технологий) к разработке новой версии протокола, который получил название EMV 3-D Secure 2.0.
Он похож на своего предшественника, но вводит ряд существенных улучшений. Первая черновая (draft) версия спецификации EMV 3DS имела номер 2.0.1. Первая рабочая версия имеет номер 2.1.0. Перечислим ее основные возможности и особенности:

Frictionless-аутентификация. Протокол позволяет при помощи рискового анализа (Risk-based analysis или RBA) выполнить так называемую Frictionless-аутентификацию, то есть подтвердить принадлежность карты плательщику без его непосредственного подтверждения. Это одно из важнейших нововведений, которое влечет за собой основные преимущества нового протокола: удобство для клиента и повышение уровня конверсии для ТСП.

Поддержка нескольких «каналов» (channel) проведения аутентификации:

браузерный (browser-based или BRW) – привычный канал оплаты из интернет-магазина через браузер на десктопе, мобильном устройстве, и т.д.;

из приложения (application-based или APP) – 3DS-аутентификация выполняется непосредственно из мобильного приложения (браузер отсутствует), при этом за реализацию функций EMV 3DS отвечает специальная интегрированная в приложение библиотека SDK. Это позволяет улучшить пользовательский опыт, т.к. аутентификация проходит в нативном окружении платежного приложения (никаких больше корявых HTML-страниц!). При этом собираются дополнительные данные об устройстве, что важно для «узнавания» рисковой машиной клиента и повышает безопасность проводимой операции;

инициированный ТСП (3DS requestor initiated или 3RI) – инициируется магазином самостоятельно, без запроса держателя. Этот канал может быть использован для подписок, регулярных платежей и т.д.;

Поддержка двух «категорий» (category) аутентификации:

платежная (Payment или PA) – держатель аутентифицируется для того, чтобы совершить оплату товара или услуги, совершить денежный перевод;

неплатежная (Non-Payment или NPA) – держатель аутентифицируется при совершении операции, не предполагающей дальнейшего движения денежных средств. Например, привязка карты к сервису, проверка при токенизации карты, и т.п.;

Защищенность информационных потоков. В отличие от первой версии 3DS 1.0.2, в которой прикладные данные передаются через браузер, все значимые данные в EMV 3DS передаются через защищенную среду напрямую между компонентами платежной 3DS-инфраструктуры. Пользовательское устройство задействуется только для выполнения технических запросов при взаимодействии с ACS Эмитента;

Поддержка гибкой системы рискового анализа, которая, помимо выполнения Frictionless, может реагировать и на угрозы, в том числе с применением социальной инженерии. Если система фиксирует нетипичный для данного клиента денежный перевод, например, с незнакомого устройства или из другой страны, то такая операция может быть заблокирована, либо может потребовать усиленных методов аутентификации. Для подтверждения может потребоваться не только ввод одноразового пароля, но и ответы на дополнительные контрольные вопросы или введение биометрических данных. Разумеется, это не защищает от соц. инженерии на 100 % (если держатель хочет отдать свои деньги мошенникам, он их отдаст), но снижает вероятность успешного мошенничества по сравнению с первой версией 3DS.

Как видим, имеющиеся проблемы 3DS 1.0.2 в значительной степени решаются EMV 3DS 2.0. Кроме того, протокол активно развивается, платежные системы и банки занимаются внедрением его следующей версии – 2.2.0 (а на очереди уже 2.3.0), которая вводит ряд дополнительных возможностей. Но об этом в конце нашей статьи.

Схема работы EMV 3-D Secure 2.0

Протокол 3-D Secure 2.0 построен поверх HTTPS протокола с использованием сообщений в формате JSON (почему JSON предпочтительней XML, который использовался в 3-D Secure 1.0, можно почитать тут или тут). Состав доменной модели не изменился (описание можно посмотреть в разделе «Схема работы 3-D Secure 1.0.2» в предыдущей статье). Основные изменения коснулись именно схемы работы, упрощенная модель которой представлена на рисунке ниже.

В EMV 3DS добавлен новый информационный поток между 3DS Server (как теперь называется MPI) и DS. В нем 3DS Server периодически получает с DS запросом PReq (1) информацию о подписанных на протокол карточных диапазонах Эмитентов и их параметрах. В ответном сообщении PRes компонент DS для каждого карточного диапазона возвращает поддерживаемую версию протокола, дополнительные опции, а также адрес 3DS Method URL. 3DS Method URL – это URL-адрес компонента ACS, который должен вызваться 3DS Server-ом в браузере перед аутентификацией пользователя. Благодаря этому вызову ACS может выполнить идентификацию устройства, собрать его параметры и при получении запроса на аутентификацию связать его с этими данными.

Аутентификация клиента при совершении операции через браузер (Browser-based) состоит из следующих основных шагов:

Оформление заказа в интернет-магазине с оплатой онлайн. Покупатель на платежной странице интернет-магазина вводит реквизиты карты и нажимает «Оплатить»;

Интернет-магазин передает информацию о платеже в 3DS Server;

3DS Server при наличии 3DS Method URL инициирует его вызов в браузере клиента, после чего формирует сообщение AReq (2), которое содержит:

данные об интернет-магазине;

собранную информацию о клиентском устройстве.

Сообщение AReq передается в DS;

DS проверяет AReq, определяет Эмитента карты и отправляет AReq (3) в ACS;

ACS на основе данных из AReq и собранных данных об устройстве (3DS Method) принимает решение о необходимости и способе дополнительной проверки покупателя;

ACS возвращает в DS ответ – сообщение ARes (4). В нем ACS передает свое решение по аутентификации. При необходимости дополнительного подтверждения так же передается адрес страницы ACS;

DS проверяет сообщение ARes и передает его в 3DS Server (5);

3DS Server проверяет сообщение и анализирует принятое ACS решение:

если ACS подтвердил успешную аутентификацию (например, используя рисковый анализ), то стадия 3DS на этом завершается. 3DS Server инициирует проведение платежной авторизации и перенаправляет браузер покупателя обратно в интернет-магазин, где отображается результат оплаты;

если ACS потребовал дополнительное подтверждение, то 3DS Server формирует сообщение CReq (6), которое передается через браузер на URL-адрес ACS, полученный в ARes.

ACS отображает страницу с пользовательским интерфейсом для аутентификации покупателя;

Покупатель вводит полученный код и нажимает «Подтвердить». В ACS отправляется запрос с введенным одноразовым кодом;

ACS проверяет одноразовый код и выполняет отправку сообщения RReq (7) с результатами аутентификации в DS;

DS проверяет сообщение и передает его в 3DS Server (8);

3DS Server проверяет сообщение, фиксирует результат аутентификации и в ответ формирует сообщение RRes (9). Оно нужно, чтобы проинформировать DS и ACS об успешном получении RReq с результатами аутентификации;

DS проверяет сообщение RRes и передает его в ACS (10);

ACS проверяет сообщение RRes и выполняет формирование сообщения CRes (11), которое через браузер передается на адрес 3DS Server. CRes-сообщение требуется, чтобы вернуть браузер пользователя со страницы ACS обратно в интернет-магазин;

3DS Server получает CRes, проверяет его и, в случае успеха, инициирует финансовую часть операции;

3DS Server перенаправляет браузер в интернет-магазин с информацией о результате проведения операции.

В случае Application-based канала, схема взаимодействия имеет лишь незначительные отличия, поэтому отдельно ее рассматривать не будем.

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

История запуска 3-D Secure в ПС «Мир»

В платежной системе «Мир» вопрос запуска технологии 3-D Secure встал вместе с запуском самой платежной системы в 2015 году. Пускать в полномасштабный тираж в масштабах страны карту без защиты платежей в интернете было невозможно, поэтому параллельно с наладкой и запуском платежной системы, проводилась работа по реализации сервиса 3-D Secure и подготовка сопутствующих правил и регламентов для банков. На старте было заключено соглашение с другой платежной системой, владеющей лицензионными правами на технологию 3DS 1.0.2. Это решение, с одной стороны, гарантировало корректность работы всей платежной инфраструктуры, включая сайты торгово-сервисных предприятий (ТСП), банков и платежных сервис-провайдеров. С другой стороны, обеспечивало максимальную скорость решения задачи. 3DS-сервис для карт национальной платежной системы получил название MirAccept.

Запуск собственной платформы MirAccept занял почти два года. За это время было подготовлено техническое задание, выполнена разработка, проведено тестирование, приемка и внедрение. Запускалась платформа с поддержкой одновременно двух протоколов: MirAccept 1.0, основанного на 3-D Secure 1.0.2, и MirAccept 2.0, основанного на современном стандарте EMV 3-D Secure 2.0. Одновременно с запуском платформы решался еще целый ряд задач, таких как создание сертификационной среды для проверки соответствия банков правилам и стандартам сервиса, разработка тестовых сценариев, написание руководств и регламентов по сертификации и подключению, разработка бизнес-процессов подключения и прочее. Благодаря слаженной работе команды, в сентябре 2017 года собственная платформа MirAccept была успешно запущена, и с пилотными банками были проведены первые промышленные операции оплаты с аутентификацией держателя через собственный сервис MirAccept.

На момент запуска нового протокола MirAccept 2.0 (в 2017 году) о протоколе EMV 3-D Secure 2.0, на котором он основан, в банковской среде практически не знали. ПС «Мир» в этом смысле стала новатором, запустив этот протокол первой из всех крупнейших платежных систем (и, возможно, первой вообще). НСПК фактически стала драйвером по продвижению новой технологии в платежном пространстве РФ. С 2017 года начинаются обучающие семинары и лекции, причем не только для банковских специалистов, которым вскоре предстояло внедрять соответствующие программные комплексы в своих банках, но и для разработчиков и поставщиков программных решений. Для разных целевых аудиторий были разработаны курсы различной степени погружения и детализации. Они включали широкий круг тем – от верхнеуровневого обзора технологии, до рассмотрения деталей реализации требований спецификации, криптографических операций и программных методов интегрируемого в платежное приложение SDK. В настоящий момент платежный рынок с технологией знаком уже достаточно тесно, и потребность в обучении снизилась. Тем не менее периодически мы и сейчас проводим семинары (а в текущих условиях вебинары), посвященные принципам работы технологии, процессам сертификации, а также подключения к сервису Банков и платежных провайдеров.

Вскоре после запуска Платформы MirAccept стало понятно, что Банкам нужна помощь в проведении рисковой оценки операций, т.к. на внедрение собственных систем рискового анализа не всегда есть время и ресурсы. С другой стороны, без этой функциональности переход на новый протокол обозначал лишь замену старых сообщений 3DS 1.0.2 новыми сообщениями EMV 3DS 2.0 без изменения пользовательского опыта. Именно frictionless-аутентификация без дополнительного подтверждения от держателя карты, при сохранении уровня безопасности, является главным преимуществом нового протокола. И для того чтобы она работала, была необходима система рискового анализа.

Исходя из этих соображений, уже в конце 2017 года было проведено предпроектное исследование, а в 2018 году запущен проект по созданию собственной RBA-машины, которая получила название Сервис принятия решений (СПР).

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

Если говорить про перспективы рискового анализа в целом, то уже сейчас возможно с высоким качеством оценивать 40-60 % операций в так называемую «зеленую зону», то есть не требовать по ним дополнительного подтверждения платежа от держателя. Некоторые банки используют для этого СПР, другие пользуются собственными решениями по рисковому анализу.

На сегодняшний день развитием Платформы 3-D Secure в НСПК занимается выделенная команда. Совсем недавно ядро нашей Платформы (компонент Directory Server) успешно прошло сертификацию в независимой тестовой лаборатории EMV, и мы получили подтверждение соответствия нашего компонента требованиям последней действующей версии спецификации EMV 3DS 2.2.0. Это открывает для нас возможность предоставления банкам-участникам новых возможностей на базе спецификации 2.2.0. Далее мы хотим рассказать об этих возможностях.

Новые возможности в EMV 3DS 2.2.0

Выпущенная в конце декабря 2018 года версия спецификации 2.2.0 содержит важные нововведения и улучшения:

Платежная аутентификация в 3RI канале. В 2.1.0 версии для 3RI была возможна только неплатежная аутентификация (NPA), уместная, например, при привязке карты к личному кабинету, электронному кошельку и т.д., что не востребовано для операций, инициируемых ТСП без участия держателя. В 2.2.0 стала возможна и реализация платежной аутентификации (PA) в рамках 3RI. Причем сценарий аутентификации возможен как Frictionless, так и Challenge. В последнем случае используется новый подход к аутентификации – Decoupled Authentication.

Decoupled Authentication или отложенная аутентификация – это подход, при котором проверка держателя карты может быть отложена во времени. Метод аутентификации, который будет при этом использоваться, остается на усмотрение эмитента. Например, это может быть звонок из банка клиенту в удобное для него время, запрос подтверждения по e-mail или через мобильное приложение. Ключевым является то, что подтверждение требуется не в сам момент проведения операции, а может быть выполнено в течение длительного периода времени, до семи дней.
Для проведения отложенной аутентификации 3DS Server отправляет в запросе AReq специальный флаг, указывающий на возможность проведения отложенной аутентификации. ACS, исходя из настроенного для конкретной карты метода аутентификации, может согласиться с проведением отложенной аутентификации или нет. Если он соглашается, то аутентификация проводится выбранным способом. По итогу проведенной проверки клиента ACS отправляет стандартное сообщение с результатом аутентификации (RReq) платежной системе (в DS), после чего оно перенаправляется банку Эквайреру в 3DS Server. Преимущество данного метода состоит в том, что подтверждение клиента никак не привязано к процессу покупки услуги или сервиса, что может быть успешно использовано, например, для следующих видов 3RI платежей:

подписка на сервис (рекуррентные платежи – ежемесячные оплаты услуг провайдеров связи и интернета, аренда, услуги онлайн-кинотеатров и т.д.);

продление страховых и прочих услуг (продление страхового полиса, покупка новых услуг по предварительной договоренности с клиентами и т.п.).

Whitelisting. Еще одно нововведение спецификации 2.2.0 – это возможность для клиента добавить ТСП (интернет-магазин или иную компанию, в адрес которой производится оплата) в список доверенных (whitelist) на стороне Эмитента. На странице аутентификации держатель имеет возможность подтвердить добавление в белый список данного ТСП. Обязательным условием добавления в белый список является успешно проведенная аутентификация по Challenge-сценарию. При этом ACS дополнительно может проинформировать 3DS Server об успешном добавлении данного магазина в белый список.

По итогу Эмитент может проводить последующие операции из этого ТСП по этой карте без дополнительного обращения к держателю карты, то есть по frictionless-сценарию, т.к. клиент дал на это осознанное согласие. Кроме того, банк Эквайрер при последующих оплатах также может запрашивать проведение операции по frictionless на основании того, что ТСП находится в белом списке. Держатель карты получает контроль над тем, в каких магазинах он разрешает оплату без доп. подтверждения, что в итоге улучшает клиентский опыт. Магазин при этом получает увеличение конверсии, т.к. убирается лишний барьер для клиента в виде обязательного подтверждения операции.
По сути whitelisting является простым и дешевым способом реализовать преимущества EMV 3DS 2.0 без создания сложной RBA-машины.

Перспективы внедрения 2.2.0 на рынке

Как видим, все нововведения в 2.2.0 направлены прежде всего на улучшение клиентского опыта и увеличение конверсии. Клиент на сегодняшний день очень требователен к удобству процесса оплаты, поэтому интернет-магазины находятся в бесконечной гонке по созданию различных гибких сценариев оплаты. Возможность добавления в белые списки (Whitelisting), например, поможет клиентам, которые постоянно оплачивают покупки на одних и тех же сайтах, делать это более удобно, не отвлекаясь на дополнительные окна и ввод кодов подтверждения. А новые механизмы отложенной аутентификации (Decoupled Authentication) позволят интернет-магазинам и банкам-эквайрерам значительно повысить конверсию рекуррентных платежей. В данный момент такие платежи считаются небезопасными, т.к. в процессе платежа не проверяется личность клиента (платежи проходят без 3DS). Новая технология от EMVCo позволяет проверить клиента удобным для него способом, например, через то же банковское приложение с помощью Push-уведомления, не заставляя его при этом одновременно идти на сайт и совершать платеж.

Кроме того, EMV 3DS 2.0 позволяет использовать специальные служебные поля (т.н. Extension fields) для безопасной передачи дополнительной информации между Участниками процесса аутентификации. Из последних изменений, например, появилась возможность передачи дополнительных данных о пассажире от магазина (авиаперевозчика или туроператора) к банку Эмитенту (т.н. Airlines Data или «Длинная запись»). Об этом изменении EMVCo выпущен отдельный бюллетень, разъясняющий правила использования служебных полей для этих целей (Travel Industry Message Extension). Эта и подобные возможности дают шанс реализовать сложные задачи в рамках современного быстро развивающегося рынка e-commerce и ставят перспективы развития технологии EMV 3DS 2.0 на ступень выше своего предшественника.

Заключение

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

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

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

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

Платежная аутентификация для merchant-initiated платежей также повысит конверсию платежей по подпискам на регулярные сервисы, которые становятся особенно востребованными в последние годы вместе с переходом на сервисную модель потребления.

Таким образом, в ближайшие несколько лет мы предполагаем решение большей части проблем, связанных с наследием технологии 20-летней давности, 3-D Secure 1.0.2, и изменение в лучшую сторону пользовательского опыта при совершении платежей по банковским картам в сети интернет.

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

Источник