3-D Secure

3-D Secure — это протокол аутентификации держателя платежной карты при совершении онлайн-транзакций, реализующий многофакторную проверку личности владельца счета с помощью данных, передаваемых через дополнительный промежуточный сервер (сервер каталога — Directory Server). Протокол был разработан компанией Visa под названием «Verified by Visa» для карт Visa и «MasterCard SecureCode» для карт MasterCard (в настоящее время брендирование унифицировано как «Verified by Visa» и «MasterCard Identity Check»). Основная цель 3-D Secure — снижение риска мошенничества при оплате в интернете путем подтверждения, что инициатором списания средств является именно авторизованный держатель карты, а не третье лицо, завладевшее её реквизитами (PAN, срок действия, CVV2/CVC2).

История и развитие

Первая версия протокола (3-D Secure 1.0) была внедрена в начале 2000-х годов в ответ на резкий рост интернет-торговли и связанного с ней фальшивого использования данных банковских карт. Разработка велась под эгидой Visa и MasterCard, которые стремились создать единый стандарт безопасности для своих платёжных систем. Изначально протокол работал на основе переадресации пользователя на страницу банка-эмитента, где требовалось ввести статический пароль, полученный при регистрации в сервисе (Verified by Visa или SecureCode). Этот подход вызывал критику из-за неудобства и уязвимости к фишинговым атакам, когда злоумышленники подделывали страницу банка.

В ответ на эти недостатки, а также с учётом требований европейской директивы PSD2 (Revised Payment Services Directive), которая с 2019 года сделала обязательным сильную аутентификацию клиента (Strong Customer Authentication — SCA) для большинства онлайн-платежей в Европейской экономической зоне, платёжные системы разработали новую версию — 3-D Secure 2.0 (и её последующее обновление 2.1, 2.2, 2.3). Внедрение версии 2.0 началось массово с 2019–2020 годов. В России адаптация протокола регулируется прежде всего рекомендациями Центрального банка и правилами самих платёжных систем, а также общим законодательством о защите информации (Федеральный закон № 152-ФЗ «О персональных данных»).

Архитектура и участники

Название протокола отражает его трёхзвенную архитектуру. Участниками процесса являются три домена (три «D»):

Домен эмитента (Issuer Domain)

Это зона ответственности банка-эмитента (кредитной организации, выпустившей карту). Включает:

• Сервер контроля доступа эмитента (Access Control Server — ACS). ACS принимает решение о необходимости аутентификации, генерирует одноразовые коды (например, по SMS или push-уведомлению), проверяет введённые данные и формирует результат проверки.
• Базу данных зарегистрированных в сервисе карт и методов связи (номер телефона, адрес электронной почты).
• Интерфейс для взаимодействия с держателем карты (веб-страница или push-интерфейс в мобильном приложении банка).

Домен приобретателя (Acquirer Domain)

Это зона ответственности банка-эквайера (банка, обслуживающего точку продажи — интернет-магазин, платёжный агрегатор) и самого торгового предприятия. Включает:

• Платёжный шлюз или интернет-магазин (Merchant Plug-in — MPI). MPI инициирует запрос на аутентификацию.
• Систему обработки транзакций эквайера.

Домен взаимодействия (Interoperability Domain)

Это инфраструктура платёжных систем (Visa, MasterCard, Мир и др.). Включает:

• Сервер каталога (Directory Server — DS): центральный реестр эмитентов, который определяет, какой ACS обслуживает данную карту, и перенаправляет запросы.
• Шлюз истории (History Server): хранит записи всех попыток аутентификации для анализа мошенничества и взаиморасчётов.

Механизм работы (на примере версии 2.x)

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

1. Инициация и передача данных. Покупатель на сайте магазина заполняет платёжную форму (номер карты, срок действия, CVV2/CVC2). Система магазина (MPI) отправляет запрос (Authentication Request — AReq) на сервер каталога (DS) платёжной системы. В запросе, помимо реквизитов карты, содержится информация о контексте: IP-адрес и геолокация устройства покупателя, данные его браузера (User-Agent, screen resolution, time zone), история предыдущих покупок на этом сайте, сумма транзакции. Эти данные ранее были недоступны в версии 1.0.

1. Маршрутизация. DS анализирует BIN-номер карты (первые 6–8 цифр) и направляет запрос к соответствующему ACS банка-эмитента.

1. Анализ рисков. ACS банка-эмитента оценивает риск транзакции на основе полученных контекстных данных и набора правил, заданных банком и клиентом. Если риски низкие (например, покупка с того же устройства, с которого обычно совершаются платежи, на сайте, где покупатель уже был), ACS может принять решение не требовать дополнительной интерактивной аутентификации. В этом случае запрос получает статус «Approve» без участия пользователя (бесшовная аутентификация — frictionless).

1. Интерактивная аутентификация. Если риск высок или транзакция необычна (например, новый продавец, другое устройство, превышение лимита), ACS требует подтверждения. Он генерирует одноразовый код (обычно 6–8 цифр) и отправляет его держателю карты по выбранному каналу: SMS, push-уведомление в мобильное приложение банка, код из мобильного приложения-аутентификатора, биометрическая верификация (Face ID, Touch ID на телефоне) или стационарный пароль. Пользователь вводит этот код в специальное окно, которое может быть встроено в страницу магазина или открываться через мобильное приложение. Возможно отображение суммы и получателя.

1. Формирование ответа. ACS формирует ответ (Authentication Response — ARes), который содержит криптографический токен (CAVV — Cardholder Authentication Verification Value или UCAF — Universal Cardholder Authentication Field), подтверждающий успешную аутентификацию. Этот ответ отправляется обратно в DS, который передаёт его в MPI.

1. Авторизация. MPI передаёт код аутентификации (токен CAVV/UCAF) в авторизационный запрос к платёжной системе. Платёжная система сверяет токен и завершает транзакцию. Согласно правилам платёжных систем, в случае успешной аутентификации по протоколу 3-D Secure (версии 2.0 или 1.0), бремя ответственности за мошенничество (chargeback) перекладывается с торговой точки на банк-эмитент. Это является ключевым стимулом для продавцов внедрять протокол.

1. Оповещение. ACS может отправить держателю карты итоговое push-уведомление об успешном платеже.

Версии протокола: 1.0 против 2.x

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

Преимущества

• Снижение мошенничества: Протокол существенно затрудняет несанкционированное использование украденных данных карты, так как злоумышленник, даже зная номер, срок и CVV, не может пройти второй фактор (одноразовый код, биометрию).
• Перенос ответственности: Для торговых точек (интернет-магазинов) это единственный способ переложить риск chargeback (возврат средств по требованию держателя карты при списании) на банк-эмитент. Без 3-D Secure эмитент может опротестовать операцию как мошенническую, и убыток ложится на продавца.
• Удобство (версия 2.x): Бесшовная аутентификация (frictionless) для большинства привычных покупок не ухудшает пользовательский опыт. Пользователь даже не замечает, что проверка прошла.
• Интеграция с мобильными устройствами: Современные версии поддерживают push-уведомления и биометрию, что удобно для пользователей смартфонов.

Критика и недостатки

• Сложность внедрения (версия 2.x): Требует модернизации платёжных шлюзов, MPI и банковской инфраструктуры. Не все мелкие продавцы и региональные банки оперативно переходят на версию 2.x.
• Зависимость от канала связи: Аутентификация по SMS может быть ненадёжной (задержки доставки, перехват SIM-карт, атаки SS7). Push-уведомления требуют установленного мобильного приложения банка.
• Пользовательский опыт в редких случаях: В случае ошибок (например, не приходит код) пользователь может быть вынужден совершить несколько попыток или вовсе отказаться от покупки.
• Уязвимости (версия 1.0): Версия 1.0 была уязвима для фишинга, когда мошенники создавали поддельную страницу банка, имитирующую ввод пароля.
• Приватность: Хотя данные о контексте не содержат персональных данных в явном виде, их сбор и анализ поднимают вопросы о неприкосновенности частной жизни и соблюдении правил GDPR (в Европе) и Федерального закона № 152-ФЗ (в России).
• Зависимость от платёжных систем: Протокол является закрытым стандартом, контролируемым консорциумом EMVCo (Visa, MasterCard, American Express, Discover, JCB, UnionPay). Критики отмечают, что это усиливает монополию данных в руках крупных платёжных систем.

Применение и альтернативы

3-D Secure является наиболее распространённым протоколом для защиты интернет-платежей в мире. Он обязателен к использованию для транзакций в рамках PSD2 в Европе и активно поддерживается платёжной системой «Мир» (российский стандарт «Мир Accept» базируется на 3-D Secure). Альтернативой могут быть:

• Сторонние платёжные шлюзы с собственной аутентификацией (например, PayPal — организация, зарегистрированная как иностранный агент? Нет, PayPal не признан иноагентом/экстремистской; работает в РФ с ограничениями).
• Использование токенизации (Apple Pay, Google Pay, Samsung Pay) и биометрии на уровне устройства, что в некоторых случаях может заменить полный процесс 3-D Secure, но часто используется в паре с ним.
• Аутентификация на основе биометрических данных (по голосу, лицу) в колл-центрах.

Интересные факты

• Расшифровка 3-D Secure: «3-D» означает «Three Domains» (три домена: эмитент, эквайер, взаимодействие).
• Глобальное внедрение версии 2.0 было ускорено пандемией COVID-19, когда резко вырос объём интернет-покупок, и финтех-компании начали требовать более надежной защиты.
• Согласно ежегодным отчётам Visa (среди зарубежных компаний, не признанных нежелательными), доля мошеннических chargeback без 3-D Secure версии 2.0 примерно в 2–3 раза выше, чем с ним.

Регулирование в России

В России использование 3-D Secure регулируется прежде всего нормативными актами Центрального банка РФ (Положение № 383-П «О правилах осуществления перевода денежных средств», рекомендации для кредитных организаций по кибербезопасности) и правилами платёжных систем (Visa, MasterCard, «Мир»). Для карт платёжной системы «Мир» обязательным является использование технологии «Мир Accept», которая является российской реализацией протокола 3-D Secure (построена на тех же принципах, но с использованием национальных криптографических алгоритмов ГОСТ). Российские банки активно мигрируют на версию 2.x для соответствия международным стандартам и снижения рисков.

Источники

• Положение Банка России № 383-П «О правилах осуществления перевода денежных средств».
• EMVCo. 3-D Secure 2.x Protocol and Core Functions Specification.
• Visa. Verified by Visa: Implementation Guide.
• MasterCard. MasterCard Identity Check: Technical Overview.
• Центральный банк РФ. Методические рекомендации по защите информации при осуществлении переводов денежных средств.
• PCI Security Standards Council. PCI DSS v4.0. — Requirement 6.4 (аутентификация) и 9.0 (физическая безопасность).