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

Технология была разработана для платежной системы Visa с целью улучшения безопасности интернет -платежей в рамках услуги Verified by Visa (VbV). Услуги, основанные на данном протоколе, были приняты платежными системами Mastercard под названием Mastercard SecureCode (MSC) и JCB International как J/Secure , AmEx как SafeKey , Мир ( НСПК ) как Мир Accept . American Express добавили 3-D Secure 8 ноября 2010 года под названием American Express Safe Key и первоначально сделали ее доступной лишь на некоторых рынках. Платежная система «Мир» первоначально лицензировала реализацию первой версии протокола у VISA. В 2016 г. «Мир» самостоятельно реализовала поддержку 3D-Secure 2.0 и начала предоставлять её под названием MirAccept .

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

3-D Secure code не следует путать с кодом CVV2 или CVC2 , который напечатан на карте с обратной стороны.

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

На июль 2016 года 3D-Secure поддерживали банки из 195 стран мира .

Описание с точки зрения пользователя

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

От держателя требуется ввести код подтверждения, предоставляемый банком для каждой операции чаще всего в sms-сообщении, отправленном на привязанный к карте номер сотового телефона . Возможны и другие варианты получения кода подтверждения платежа, такие как карты с микропроцессорами, с карточки одноразовых кодов; из специального устройства, которое генерирует обновляемые псевдослучайные коды . Ряд банков использует обычную систему постоянных паролей, то есть пользователь задаёт пароль один раз (при регистрации) и при совершении каждого интернет-платежа вводит именно его. Данный способ является менее надёжным, нежели одноразовый код подтверждения. Формат 3-D Secure code может варьироваться в зависимости от банка-эмитента. Обычно это 4—10 букв и цифр. Решения с одноразовым паролем состоят из 6—8 цифр .

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

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

Проблемы с безопасностью

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

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

Следовательно, это означает, что платеж в таком интернет-магазине пройдет без подтверждения по СМС или логину и паролю, а только лишь по введенным реквизитам карты, указанным на самой карте (тип, номер и срок карты, имя держателя и трехзначный CVV2 , который напечатан на карте с обратной стороны).

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

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

Основные аспекты протокола

Основная концепция протокола — добавить к процессу финансовой авторизации онлайн-проверку подлинности. Эта проверка подлинности основана на принципе трёх доменов (отсюда 3-D в названии) ^{[ источник не указан 3174 дня ]} :

• Домен эквайера (домен продавца и банка, в который перечисляются деньги);
• Домен эмитента (домен банка, выдавшего карту);
• Домен совместимости (interoperability domain) (домен, предоставляемый платёжной системой ( Mastercard , Visa и т. д.) для поддержки протокола 3-D Secure).

Перенос ответственности

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

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

Примечания

Ссылки

• от 15 февраля 2013 на Wayback Machine (англ.)
• (англ.)
• (англ.)
• от 13 октября 2010 на Wayback Machine (англ.)
• от 17 января 2013 на Wayback Machine
• Леонид ЧУРИКОВ. от 16 декабря 2013 на Wayback Machine // Банки.ру, 14.11.2012
• от 17 апреля 2021 на Wayback Machine // Журнал ПЛАС, 05.03.2021
• (неопр.) . Банки.ру. Дата обращения: 24 апреля 2020. 7 августа 2020 года.

Стандарты и документация

• (неопр.) . MasterCard (17 июня 2014). Дата обращения: 24 апреля 2020. 2 июля 2021 года.
• (англ.) . usa.visa.com. Дата обращения: 24 апреля 2020. 4 мая 2020 года.
• (англ.) . EMVCo. Дата обращения: 24 апреля 2020. 2 мая 2020 года.
• (неопр.) . Secure Trading (4 июня 2019). Дата обращения: 24 апреля 2020.
• (неопр.) . Braintree Developer . Дата обращения: 24 апреля 2020. 6 апреля 2020 года.
• Christopher Rotsaert. (англ.) (7 мая 2019). Дата обращения: 24 апреля 2020. 3 июля 2020 года.

Для улучшения этой статьи желательно : Исправить статью согласно стилистическим правилам Википедии . Проставить сноски , внести более точные указания на источники. После исправления проблемы исключите её из списка. Удалите шаблон, если устранены все недостатки.