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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Введение

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

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

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

Меня зовут Алексей Касякин, я технический владелец платформы 3-D Secure в НСПК. Вместе с Сергеем Лысенко (в НСПК руководит развитием EMV 3DS 2.0) и Алексеем Крутиковым (лидер команды разработки платформы) мы хотим рассказать про технологию 3-D Secure, ее историю, основные проблемы и перспективы развития. А также о том, почему не надо бояться, если перестал приходить одноразовый пароль.

Краткая история 3-D Secure 1.0

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

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

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

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

Протокол описывает взаимодействие трех сторон, называемых доменами (domain), что отражено в названии "3D". Принятие решения о возможности совершения операции с привлечением трех независимых доменов стало основной идеей технологии.
Выделим эти домены и зоны их ответственности:

  • Домен Эмитента - включает держателя карты и банк, выпустивший эту карту (Эмитент). В зоне ответственности этого домена лежит аутентификация держателя карты, то есть подтверждение факта легитимного владения картой лицом, совершающим операцию. Основной 3DS-компонент в домене Эмитента называется ACS (Access Control Server).

  • Домен Эквайрера – включает интернет-магазин и банк, обслуживающий его счет и операции (Эквайрер). Этот домен отвечает за выстраивание коммерческих отношений с покупателем, а также за проведение финансовой составляющей операции через платежную систему. Именно из домена Эквайрера инициируется проведение платежной операции. Основной 3DS-компонент в домене Эквайрера называется MPI (Merchant Plugin Interface).

  • Домен взаимодействия – это платежная система (ПС). Платежная система обеспечивает взаимодействие между доменом Эквайрера и доменом Эмитента, устанавливает правила этого взаимодействия, определяет требования к безопасности, а также предоставляет возможность совершения финансовой части операции. Основной 3DS-компонент в домене ПС называется DS (Directory Server).

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

Выполнение платежа состоит из следующих шагов:

  • Держатель карты оформляет заказ в интернет-магазине с оплатой онлайн, на платежной странице вводит реквизиты карты и нажимает кнопку «Оплатить»

  • Данные с платежной страницы передаются в MPI

  • MPI отправляет в DS сообщение VEReq (1) с номером карты и данными об интернет-магазине

  • DS проверяет VEReq-сообщение, определяет банк-эмитент карты и отправляет сообщение VEReq (2) в ACS

  • ACS проверяет VEReq-сообщение и определяет возможность проведения аутентификации покупателя по 3-D Secure, после чего формирует сообщение VERes (3). Если проведение аутентификации возможно, в VERes передается URL страницы ACS, на которую должен быть перенаправлен пользователь. Сообщение VERes передается в DS

  • DS проверяет сообщение VERes и возвращает его обратно в MPI (4)

  • MPI формирует сообщение PAReq (5) с информацией об операции и техническими данными от ACS. Сообщение передается через браузер на URL-адрес ACS, полученный в VERes

  • ACS в ответ на запрос браузера PAReq (6) возвращает форму аутентификации держателя карты. Держатель видит поле ввода одноразового пароля

  • Держатель вводит полученный по sms/push код и нажимает кнопку «Подтвердить», код отправляется в ACS

  • ACS проверяет код и формирует сообщение PARes с результатом аутентификации и данными для выполнения финансовой составляющей операции. Сообщение PARes (7) передается через браузер на адрес MPI

  • MPI получает от браузера PARes (8), проверяет сообщение, включая подпись, и, в случае успеха, инициирует проведение финансовой части операции (авторизации)

  • MPI получает результат проведения авторизации и перенаправляет браузер обратно в интернет-магазин, держатель видит результат проведения платежа

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

Этапы развития 3-D Secure в России

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

  • Статичный пароль. Наиболее простой способ, внедрялся одним из самых ранних. При первом платеже из интернет-магазина клиент переадресовывался на ACS, где должен был придумать пароль, заполнив регистрационную форму. Созданный пароль привязывался к карте. При последующих платежах появлялась страница аутентификации, где нужно было вводить этот пароль. Преимуществами этого способа была относительная простота и возможность быстро поменять пароль при необходимости. Какое-то время данный способ аутентификации считался безопасным и удобным. Но вскоре безопасность статичных паролей стала падать: их крали у клиентов, находя через браузеры "дыры" в безопасности; в колл-центрах банков могли быть "свои" люди, которые узнавали пароли; бывали даже случаи, когда пароль находили записанным на клочке бумаги в украденном кошельке, как это бывало и с ПИН-кодами. Спустя несколько лет после запуска статичные пароли перестали считаться безопасными и платежные системы настоятельно не рекомендуют их использовать для 3DS-аутентификации.

  • Скретч-карта. Это карта, на которой информация находится под стираемым слоем. Все мы хоть раз играли в моментальную лотерею или получали в магазинах подобные карты, с которых потом монеткой стирали слой, чтобы добраться до сокровенного. Для 3-D Secure выпускались подобные карты, на каждой находилось некоторое количество одноразовых паролей. Клиенты получали эти карты в отделениях банков. При очередном платеже на странице ACS требовалось ввести один из паролей со скретч-карты. Такой подход обеспечивал более высокий уровень безопасности, но возникали другие проблемы: одноразовые коды на карте заканчивались либо карта терялась, приходилось идти в отделение банка за новой. Клиенты забывали про это и сталкивались с проблемой уже при проведении платежа. Дальше начинались попытки вводить уже использованные коды и звонки в колл-центры банков с просьбами разрешить платеж со старым кодом, что было технически невозможно. В итоге падала и конверсия, и удовлетворенность клиента.

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

  • CAP-ридер (Chip Authentication Program). Это устройство, похожее на современные мобильные терминалы, при получении карты выдавалось клиенту. В него вставлялась карта, вводился код доступа, и на экране генерировался одноразовый пароль. Такой подход обеспечивал высокую криптографическую защиту, но не получил массового распространения ввиду большой цены CAP-ридера и неудобства использования.

  • Display Card – Банковская карта с генератором случайных паролей. Чуть больше можно прочитать здесь: https://habr.com/ru/post/157891/. Такие карты были и удобны, и безопасны, т.к. генератор паролей всегда был под рукой и имел устойчивую криптографическую защиту. Но были и серьезные минусы, не позволившие подобным картам распространиться массово. В первую очередь это цена, которая не рассчитана на массового клиента. Кроме того, в карте присутствовал автономный источник питания, который мог разрядиться раньше истечения срока действия карты, и в целом подобные карты были более уязвимы к механическим воздействиям.

С 2008-2009 года мобильные операторы в РФ начали постепенно снижать тарифы на отправку SMS. Благодаря этому стало возможным применение Dynamic OTP (One Time Password), который оказалось очень удобно отправлять в SMS-сообщении на телефонный номер клиента, привязанный к карте. После переадресации клиента на ACS (сообщение PAReq) ему отправлялся пароль в SMS, после ввода которого личность держателя карты считалась подтвержденной. Так как SMS-сообщения могут быть получены любым телефоном, именно они на тот момент имели наибольший потенциал как дешевый и надежный механизм подтверждения. В последнее время есть тренд перехода на Push сообщения в качестве более дешевого для банков способа. Кроме того, их нельзя перехватить на стороне мобильного оператора. В случае с SMS именно мобильный оператор становится дополнительным звеном в цепи "доверия", а в случае с роумингом – их несколько.

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

Что потребовало улучшений в 3DS 1.0

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

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

    • Недоверие клиентов к всплывающим окнам и вводу в них кодов, страх быть обманутым.

    • Непонимание что именно требуется сделать для подтверждения оплаты.

    • Ошибки при вводе, ввод другого значения, например, ПИН; ввод не того кода со скретч-карты и т.д.

    • Плохое интернет-соединение, проблемы переадресации на ACS или обратно из ACS в магазин.

    • Отсутствие доступа к телефону, привязанному к карте.

    • Неуверенный прием, проблемы с отправкой SMS на стороне банка, либо с доставкой SMS на телефон клиента.

    • И т.п.

  • Адаптация к мобильным устройствам. Платежные системы при сертификации Эмитентов по технологии 3-D Secure 1.0 накладывали определенные требования по размеру и содержанию страницы аутентификации. Данные требования сильно ограничивают веб-разработчика в верстке этих страниц. В результате может получиться, что при попытке оплаты в красивом, современном интернет-магазине, нас переадресовывает на маленькую страницу где-то в углу экрана. При этом форма ввода кода в некоторых случаях может быть даже не видна. В случае использования мобильного устройства (доля оплат с которых растет каждый год), пользователь сталкивается с похожей проблемой: HTML-форма, предъявляемая Эмитентом, выглядит инородно в GUI мобильного приложения, ее масштаб и положение могут быть неудобны для пользователя.

  • Повышение уровня защиты от мошенничества с применением социальной инженерии. Ни один метод аутентификации по 3DS 1.0 не обеспечивает действительно надежной защиты платежа от методов мошенничества, известных под общим названием "социальная инженерия". Одноразовый код мошенники могут узнать непосредственно у клиента, введя его в заблуждение. Например, мошенник представляется сотрудником службы безопасности банка и сообщает о совершении подозрительной операции по карте клиента. Для ее отмены необходимо назвать код, который придет по SMS или PUSH. В это время по скомпрометированным реквизитам карты мошенником совершается операция денежного перевода, для которой и запрашивается код подтверждения. Аналогичным образом мошенники при звонке могут представляться сотрудниками полиции, ФСБ, судебными приставами, представителями лотереи и т.д. При этом цель у них неизменна: спровоцировать клиента на компрометацию реквизитов карты и/или одноразового кода.

  • Улучшение пользовательского опыта. За прошедшие 20 лет банки приучили клиентов, что ввод OTP – это нормально. Но в действительности менее 0,05 % всех операций являются мошенническими. То есть почти по всем операциям с вводом OTP на самом деле он не требуется, т.к. ее проводит легитимный владелец карты.

Для решения этих задач и была разработана следующая версия протокола – EMV 3DS 2.0. О его зарождении, возможностях и преимуществах, а также о его запуске в ПС "Мир" мы расскажем в следующей статье

Источник: https://habr.com/ru/company/nspk/blog/564026/


Интересные статьи

Интересные статьи

Эта часть статьи будет об осмыслении составляющих Redux. Так ли они необходимы, что является их аналогом. Также будет предложена более удобная альтернатива хука useReduc...
Выгрузка пользователей из 1C ЗУП в Битрикс24 или правдивая история о том как настроить интеграцию 1С-Битрикс24 с ЗУП без 1С-ника В жизни так бывает, причём бывает чаще чем хотелось б...
Рассказываем, как развивались способы создания презентаций до появления привычных нам сервисов. Мы привыкли делать презентации в специальных программах или онлайн-редакторах: у нас...
Материал статьи взят с моего дзен-канала. Структура RTP-пакета В прошлой статье мы с помощью TShark выполнили захват RTP-пакетов, которыми обменивались наши приемник и передатчик. Ну а в этой м...
Довольно часто музыкальную составляющую компьютерных игр затмевают геймплей и сюжет. Однако есть проекты, в которых звук не просто выходит на первый план, но становится неотъемлемой частью игрово...