В прошлой статье мы рассказали о том, как появился первый протокол надежной аутентификации для платежей по пластиковым картам 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.

Дальнейшее развитие сервис получил вместе с выходом новой версии протокола – EMV 3DS 2.0. Анализ возможностей нового протокола показал, что он будет востребован в платежном пространстве РФ, т.к. предлагает решение многих имеющихся проблем 3DS 1.0.2. В 2016 году был запущен проект по созданию 3DS-сервиса для ПС "Мир" на базе ее оператора – Национальной системы платежных карт (НСПК). Для НСПК это была новая, нетривиальная задача. Стоит заметить, что если компоненты 3DS для банков и магазинов широко распространены на рынке и предлагаются как коробочные решения, то разработка компонента в домене платежной системы – Directory Server - это задача штучная, на рынке готовых предложений таких продуктов нет. Кроме того, задача усложнялась тем, что нужно было реализовать надежный, высоконагруженный сервис на базе совершенно новой спецификации EMV 3DS 2.0, которая на тот момент существовала только в черновой версии.

Запуск собственной платформы 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 с одноразовым паролем, и почему не стоит бояться операций в интернете без дополнительного подтверждения. Всем безопасных платежей!