Безопасность и платежные системы: кому можно доверять свои банковские данные?
Больше половины россиян хоть раз в жизни сталкивались с мошенничеством с банковскими картами онлайн. Почему уходят деньги с карт, продается персональная информация и как финансовые учреждения должны защищать вас как пользователя ― от эксперта в сфере безопасности платежного сервиса Profee.
Мошенничество с банковскими картами: неутешительная статистика
По данным последнего отраслевого отчета Nilson Report, каждые 6,81 цента на 100 долларов США были присвоены мошенниками. Наибольшее число потерь выпадает на операции без предъявления банковских карт со счетов частных лиц (CNP) ― 68%. А больше всего от мошенничества страдали американцы, китайцы и россияне.
Но мошенничество — это не только единоразовое снятие с банковского счета какой-то суммы средств. Данные держателей карт, их адреса и контакты тщательно отбираются и сохраняются «на будущее». В даркнете регулярно мелькают предложения купить карту какого-то американца и не только по стоимости от 5,80 долларов за штуку. А тут и подделка личности, и кредиты, и займы, и все вытекающие. Что примечательно, именно граждане в возрасте около 30 лет наиболее подвержены мошенничеству, так как в 54% случаев они уверены, что смогут «заблаговременно» обнаружить схему. Как видим из статистики, это не так.
Давайте говорить откровенно, переход по фишинговым ссылкам или ввод банковских данных в несуществующем магазине не должны становиться причиной для утечки данных. Ключевой фактор ― степень защиты финансовой организации и платежной системы. А тут ситуация на сегодняшний день обстоит очень двояко.
Стандарты безопасности в сфере онлайн-платежей: что диктует мир?
На сегодня существует более десятка стандартов, которые описывают условия и требования к платежным операторам или системам для безопасного совершения платежей. Некоторые из них международные, некоторые ― национальные.
Первоочередные регулируют в принципе оборот дебетовых и кредитных карт, как, например, Федеральный закон «О национальной платежной системе» или «О защите прав потребителей», где берутся основные нормы проведения платежей и их регламентация. Но ключевые требования, которые диктуют меры по защите CNP-платежей:
1. ANSI X9-112-3 Мобильный банкинг и платежи ― стандарт, определяющий проведение транзакций с мобильного и осуществление платежей с мобильных банковских приложений. Например, по NFC, RFID, Bluetooth, Wi-Fi, SMS.
2. Спецификации альянса Fast Identity Online (FIDO) ― стандарты аутентификации, в том числе с использованием биометрических данных пользователя банковских услуг.
3. Спецификации веб-аутентификации W3C для безопасного Интернета (веб-API) ― рекомендации для обеспечения надежного процесса аутентификации в обход фишинговых и хакерских атак.
4. Спецификации веб-платежей W3C ― определяет нормы единого интерфейса веб-платежей для всех типов платежных операций с указанием основных характеристик платежных карт и идентификаторов способов оплаты.
5. Модель онлайн-платежей в один клик W3C ― стандарт, определяющий оплату в интернете и мобильных устройствах без регулярного ввода данных в один клик, например, через отпечаток пальца.
6. EMV 3-D Secure 2.0 ― спецификация, которая описывает нормы 3-D безопасности в сфере аутентификации на основе приложений, а также интеграцию всех платежных каналов с цифровыми кошельками.
7. Стандарт безопасности данных (DSS) индустрии платежных карт (PCI) или PCI DSS ― стандарт, описывающий меры безопасности в вопросе хранения данных держателей платежных карт для всех субъектов, участвующих в отправке, обработке и приеме платежей.
8. Стандарт безопасности данных платежных приложений PCI или PA-DSS ― документ содержит требования по обеспечению мер безопасности платежных приложений и способы оценки степени защиты.
9. PCI Point-to-Point-Encryption (P2PE) ― стандарт с требованиями к P2PE шифрованию, который описывает нормы и требования обеспечения безопасности данных учетной записи плательщиков.
10. Стандарт PCI TSP ― стандартизация поставщиков услуг токенов, которая включает требования безопасности и процедуры оценки для поставщиков услуг платежных токенов (EMV).
11. ISO: 9564-1:2017 ― Financial services — Personal Identification Number (PIN) management and security― стандарт, определяющий присвоение ПИН-кода пользователя, его использование и применение для проведения транзакций.
12. ISO 11568-1:2005 Banking — Key management (retail) – устанавливает принципы управления криптографическими ключами в розничной торговле при обмене информацией или проведению платежей без использования PIN.
13. ISO/TS 12812-2:2017 ― Core banking ― стандарт определяет условия и обязательную структуру управления сетями для проведения мобильных банковских операций (протоколы, механизмы аутентификации, цифровые подписи, сертификацию безопасности).
Вообще, стандартов и подстандартных документов в разы больше. Но это основные, которые очерчивают правила и условия безопасных платежей без предъявления карты, а также сертификацию организаций, которые являются участниками таких операций. Поэтому нужно прицельно рассмотреть реальные стандарты, которые защищают плательщика.
Реальные стандарты безопасности и практика их применения
Ключевая организация, которая занимает чуть ли не центральное место в платежной индустрии ― PCI SSC.
The PCI Security Standards Council ― Совет по стандартам безопасности PCI – представляет собой глобальный форум или организацию, которая состоит из всех заинтересованных в честных платежах сторон. Основанный в 2006 году представителями 5 международных платежных систем, он до сих пор считается ключевым в формировании норм, требований и условий платежей между финансовыми организациями и банковскими учреждениями, в том числе и C2C.
Основной документ Совета ― PCI DSS. Нормы PCI DSS покрывают работу с данными держателей платежных карт различных торгующих компаний, банков, колл-центров, платежных операторов, а также компаний, чья работа покрывает доступ к финансовой информации. Но именно платежные организации и процессинговые компании должны не просто соблюдать нормы этого стандарта, но и проходить сертификацию, чтобы подтвердить действительность мер защиты платежей.
По сути, именно эта организация и именно стандарт борется за то, чтобы любые данные сторон платежей не утекали в сторонние руки в процессе его проведения.
Специфика сертификации PCI DSS заключается не просто в оценке, что в компании все хорошо. Технические специалисты и эксперты, которые представляют сертификационный орган, проводят анализ работы компании, в частности, в отношении управления платежными операциями и хранения данных клиентов. IT-инженеры составляют сводный отчет, которые показывает уязвимые места в инфраструктуре и программном обеспечении, и в дальнейшем контролируют устранение всех пробоин в защиты. Только после построения безукоризненной защиты, компания предоставляет сертификат и допускает платежную организацию или бизнес к работе с финансовыми операциями.
На нашем платежном сервисе Profee регулярно проходит продление сертификата PCI DSS с комплексным заключением экспертов PCI. Последний мы обновили в конце начале месяца. Что это нам дает?
- Выявление технических сбоев или ошибок в работе платежного оператора. Мы своевременно узнаем, где могут проходить сбои в переводах, которые угрожают нашим пользователям.
- Определение слабых мест в защите данных. Наши специалисты могут с другой стороны взглянуть, как мошенники или хакеры могут извлекать пользовательскую информацию из базы данных.
- Контроль юридических соответствий. Эксперты помогают увидеть, где не соблюдаются нормы работы с пользовательской информацией и как это влияет на компанию.
- Повышение статуса компании. Выдача официального заключения международного аудитора подтверждает, что очередной платежный сервис ― не scam-проект, а действительно успешный финансовый стартам.
Кстати, сертификация PCI DSS ― ежегодная. Поэтому платежный сервис всегда должен держать себя в «тонусе» и мониторить требования Совета. Но стандарты PCI ― не единственные нормы, которые обязательны для ответственного платежного сервиса.
В рамках ISO стандартов финансовые платформы должны проводить платежи только с распоряжения держателей карт. В случае CNP это возможно с помощью 3ds верификации пользователя и двухфакторной аутентификации.
3-D Secure — это протокол, который подтверждает пользователя как владельца карточного счета, блокирует запрашиваемую сумму оплаты, бронирует ее на счету, и, с помощью доступа через двухфакторную аутентификацию отправляет запрос на оплату.
Чем более сложный способ двухфакторной аутентификации применяет банк, тем более надежно платежи защищены от подделки или мошенничества.
На сегодня существует несколько видов двухфакторного подтверждения:
- Через электронную подпись;
- Через токены;
- Через пароль;
- Через код в смс;
- Через персональные биометрические данные пользователя (FaceId, отпечаток пальца);
- Через определение геолокации;
- Через уведомления на сторонние устройства или приложения.
Мы в платежном сервисе Profee в процессе 3ds и двухфакторной аутентификации используем уведомления по системе защиты Verified by Visa и MasterCard Secure Code.
Это позволяет выявить, действительно ли осуществляет перевод реальный владелец карты, а не пользователь, который, например, нашел карту, а также идентифицировать держателя уникальными системами защиты всемирных платежных систем. Visa и MasterCard защищают пользователей специальным фиксированным кодом для платежных операций или одноразовым паролем. Кстати, для проведения операций с картами указанных платежных систем также нужно проходить сертификацию, чего нет у многих интернет-магазинов.
Но сертифицировать — не значит ― быть полностью уверенными в максимальной защите операций и платежных данных пользователей.
Как платежные сервисы могут убедиться, что их платежи ― за каменной стеной?
Наличие сертификатов ― не гарант реальной защиты плательщика при отправке переводов. Для того, чтобы убедиться в цифровой защит сервиса и его баз данных, партнерских платежных шлюзов, финансовые компании и платформы должны проводить penetration test (тест на проникновение).
Pentest – это метод тестирования на безопасность, который подразумевает имитацию целевых атак злоумышленников на незащищенные или слабо защищенные цепи, сети или протоколы для получения данных. В рамках норм Положения Банка России 382-П, 683-П и 684-П такие тесты в обязательном порядке должны проводить все кредитные и финансовые учреждения России один раз в год. Кстати, в рамках сертификации PCI DSS заключение об успешном прохождении пентестов также должно быть.
В отличии от классических методов оценки на защищенность сервисов и систем, задача стоит не в атаке на какие-то конкретные точки как конечную цель, а именно кража информации или перехват операций.
Мы в сервисе переводов Profee проводим пентесты не раз в год, как это требуется нормами положений, а как минимум дважды в год. Это позволяет оценить безопасность системы, возможное поведение мошенников в случае атаки, а также быстрее совершенствовать сервис, чтобы потенциальные утечки данных в принципе не могли происходить.
Кому же доверять?
Начиная с момента оформления первой карты в банке или открытия счета, стоит обратить внимание, какие сертификаты и методы защиты информации использует финансовое учреждение. Как идентифицируется владелец карты, подтверждаются и направляются платежи, получаются финансовые услуги онлайн. Кстати, не стоит лениться, чтобы заглянуть в Пользовательское соглашение и Политику обработки персональных данных. Часто там можно выяснить, как учреждение хранит данные, защищает их, и несет ли в принципе ответственность за утерю таких.
В Profee мы стараемся создать новый уровень финансового сервиса, поэтому делаем акцент на безопасность и удобство для пользователя. Если у вас есть какие-то вопросы в отношении нормативов и способов защиты платежных сервисов ― задавайте, мы с удовольствием на них ответим.
Как работает FIDO
FIDO (Fast IDentity Online) Альянс был создан в июле 2012 года для решения проблемы поддержки устройств строгой аутентификации в сети Интернет, а также с целью упростить жизнь пользователям, вынужденным создавать и запоминать имена пользователей и пароли. FIDO Альянс планирует изменить текущую ситуацию с аутентификацией путем разработки спецификаций, определяющих набор механизмов, которые вытеснят зависимость от паролей и обеспечат безопасную аутентификацию пользователей интернет-услуг. Новый стандарт по безопасности устройств и плагинов для браузеров позволит любому веб-сайту или облачному приложению взаимодействовать с широким спектром существующих и перспективных устройств для обеспечения безопасной аутентификации пользователей.

Для обеспечения безопасной работы пользователей проект FIDO объединяет аппаратные средства, программное обеспечение и интернет-сервисы.
Если кто не знаком с FIDO, перевод раздела сайта «Как работает FIDO» ниже. А сейчас небольшие комментарии.
Нашей командой разрабатывалось решение по аппаратной аутентификации на web-ресурсах. Решение получилось вполне удачным, оно используется в системах документооборота и в механизмах лицензирования SaaS. Техническая часть проекта FIDO достаточно схожа с нашими разработками и выглядит вполне выполнимой. Однако, из описания на сайте FIDO становится ясно, что четкого понимания что и как делать у них пока нет. Да и сама концепция вызывает ряд вопросов.
Безопасность
FIDO альянсом предполагается следующий механизм распространения устройств аутентификации. На этапе производства устройства получают идентификационный номер и секрет. Эта информация помещается производителем в FIDO Repository. При регистрации нового пользователя сервис запрашивает идентификационный номер устройства и по этому номеру получает из FIDO Repository данные, необходимые для проверки пользователя при аутентификации. Эти данные кэшируются интернет-сервисом в Validation Cache для снижения нагрузки на FIDO Repository.
К сожалению, о используемых криптоалгоритмах и протоколах пока ничего не сказано. Однако по косвенным признакам (в тексте встречается термин OTP, а также по схеме с Репозиторием) можно предположить, что планируется использовать симметричные алгоритмы. Для меня такое решение выглядит несколько устаревшим. Безопасное распространение симметричных ключей, чем по видимому должен заниматься Репозиторий, выглядит сомнительным. По логике вещей каждое устройство при регистрации на новом интернет сервисе должно бы генерировать новый ключ самостоятельно. То есть, для каждого сервиса свой ключ и никаких глобальных идентификационных номеров. Кроме того, что бы не хранить на сервере какие-либо секретные ключи, думается, разумно использовать ассиметричные алгоритмы.
FIDO предполагает использование двух основных типов устройств для аутентификации. В их терминологии это Identification tokens и Authentication tokens. Первый вариант не требует аутентификации владельца. То есть пока устройство подключено, аутентификация происходит прозрачно для пользователя. Несомненно удобно. Однако, этим механизмом может воспользоваться кто угодно, имеющий доступ к устройству, например жена сможет читать переписку мужа. Думаю, отказываться от второго фактора все-таки нельзя.
Приватность
Как ни печально, но использование глобального идентификатора еще и позволяет построить связь между разными учетными записями по номеру устройства, а это не всем понравится. В настоящее время и так есть серьезные проблемы с приватностью в сети интернет, а такой подход еще и усугубляет эту проблему. Думается, никаких глобальных идентификаторов быть не должно, никакой необходимости в них в общем нет.
Восстановление доступа
В концепции ничего не сказано о механизмах взаимодействия в случае утраты аппаратного устройства. Удобное и безопасное решение этого вопроса весьма важно, так как может вызвать серьезное увеличение нагрузки на техподдержку.
Решение будет очевидно востребовано некоторой частью пользователей, ведущих какую-либо коммерческую деятельность в Интернет. Однако, для широкого, повсеместного применения строгой аутентификации нужно не только обеспечить безопасность, но и предложить решение которое будет удобными и модными. Популяризация разрабатываемого решения может стать одной из самых затратных частей этого проекта. В этом плане весьма обнадеживающе выглядит участие в этом альянсе не только разработчиков, но сервисов, таких как PayPal и Google.
А вот и перевод.
Как работает FIDO
FIDO Authenticators
Пользователи будут иметь FIDO Аутентификатор или токен (любое аппаратное устройство аутентификации, поддерживающее механизмы FIDO — прим. переводчика), который они выбрали, или который им был выдан для пользования каким-либо сервисом. Например, такие устройства как биометрический сканер или USB носители с доступом по паролю. Пользователи могут выбрать такой тип FIDO Аутентификатора, который наилучшим образом отвечает их требованиям.
FIDO Аутентификаторы будет выпускаться в двух основных вариантах.
Identification tokens будут иметь уникальные ID, идентификаторы будут привязываться к аккаунту Интернет пользователя. После привязки к аккаунту, они будут доступны серверу в качестве идентификатора без необходимости каких-либо действий со стороны пользователя. Таким образом, будет обеспечиваться только один фактор аутентификации.
Authentication tokens может потребовать от пользователя выполнить какое-либо действий, чтобы доказать, что он законный владелец токена. Эти действия могут включать в себя ввод пароля, ввод PIN-кода или предоставление биометрических данных. Эти аутентификаторы обеспечат двухфакторную аутентификацию пользователя, используя принцип » что у вас есть» и «что вы знаете” или биометрический фактор „кто вы есть“.
Когда пользователь подключает свой FIDO Authenticator к аккаунту веб-ресурса, устанавливается связь между Аутентификатором, проверяющей стороной и Validation Cache. После создания связи, для проверки абонента используются одноразовые пароли (OTP). Так как пароль OTP используется только один раз, он не может быть использован для атак воспроизведения, если кто-то захватывает сеанс связи с вторжением в систему или слушает интернет-трафик.
Каждый аутентификатор будет иметь встроенный ID и начальное значение, которые позволят однозначно идентифицировать и проверить его подлинность. Криптографические операции будут происходить на борту Аутентификатора. Таким образом, даже если машина заражена вредоносным ПО, FIDO Аутентификатору еще можно доверять.
FIDO Plugin
Браузеры пользователя будут иметь FIDO плагин. Плагин сможет распознавать доступные FIDO Аутентификаторы, которые подключены к системе пользователя. Включая в себя встроенные аутентификаторы и подключаемые по USB.
При подключении пользователя к веб-сайту браузер будет сообщать серверу о доступных FIDO Аутентификаторах в составе информации о браузере. Сайты, поддерживающие технологию FIDO смогут распознать наличие аутентификатора и отвечать соответствующим образом. На основании полученной информации проверяющая сторона (веб-сайт) инициирует механизм аутентификации.
FIDO плагин может распространяться через различные каналы, в том числе:
Browser Add-On — разработчики браузеров могут иметь плагин в качестве дополнения, которое пользователи могут скачать и подключить в свой браузер.
FIDO аутентификаторы — Если пользователь покупает FIDO аутентификатор, имеющий встроенный USB диск, плагин может располагаться на нем.
Вендоры– Вендоры могут распространять плагин с новыми машинами, а также включать плагин в состав обновлений программного обеспечения для существующих машин. Эти обновления позволят использовать FIDO аутентификацию на существующих машинах с подходящими аппаратными возможностями.
Device Specific Module
Специальный модуль устройства (DSM) будет взаимодействовать с плагином для браузера с одной стороны, и с аппаратным FIDO Токеном с другой. DSM преобразует команды плагина в команды, которые являются специфическими для каждого типа токена. Разделения программного обеспечения FIDO на плагин и DSM позволяет создать универсальный плагин для браузера, поддерживающий широкий спектр аппаратных устройств. Кроме того, это позволит поставщикам аппаратных решений сосредоточиться только на разработки той части ПО, которая необходимой для поддержки своих устройств, и не потребует реализовывать весь стек программного обеспечения.
Проверяющая сторона / Website
Как следует из названия, проверяющая сторона использует проверку токена для аутентификации.
Веб-сайт распознает наличия FIDO Токена, определяет привязан ли он к аккаунту и если нет, представляет пользователю возможность привязать новый токен к своему аккаунту.
Например, определив что токен привязан к аккаунту, web-сайт добавит на страницу входа сообщение „Войти с FIDO“. Если токен был определен как сканер отпечатков пальцев, сообщение может быть „проведите пальцем для входа с FIDO“.
В зависимости от политики сервера, предпочтений пользователя и истории аккаунта Identification tokens могут значительно упростить вход в систему. Веб-сайт может просто определить существующего пользователя и показать » Welcome back Debbie!» вместо окна входа, основываясь только на информации от FIDO токена. Конечно, пользователь сможет изменить параметры входа, определив для себя, насколько опасно это может быть для его учетной записи.
Validation Cache
Validation Cache будет проверять зашифрованную информацию и одноразовые пароли получаемые от токенов, что бы быть уверенным в подлинности токена. Проверяющая сторона будет использовать Validation Cache, для проверки информации получаемой от каждого токена.
Стоит отметить, что наличие Validation Cache на сайте проверяющей стороны позволит получать ответ быстрее, избежать задержек с ответом или атак. Validation Cache будет регулярно получать обновления из FIDO Repository о новых устройствах произведенных поставщиками токенов.
FIDO Repository
FIDO Repository это центр обмена информацией о токенах. Производители токенов будут сообщать данные о каждом произведенном FIDO токене в Repository. Хранимая в Repository информация используется для проверки OTP генерируемого токеном. Repository будет регулярно обновлять Validation Cache на каждом сайте, который использует FIDO. Repository будут поддерживать большое количество сайтов и иметь механизмы репликации для обеспечения бесперебойного обслуживания. Веб-сайт сможет использовать более одного Repository.
FIDO Repository будет взаимодействовать с разработчиками, чтобы гарантировать актуальность и доступность базы токенов. Использование FIDO Repository позволит web-сайтам не иметь контактов с каждым поставщиком токенов. При подключении к FIDO Repository информация о всех существующих токенах будет доступна web-сервису.
Примеры использования
Подключение пользователя
Когда пользователь с новым токеном впервые переходит на сайт, который поддерживает технологию FIDO, сайт предположит пользователю привязать FIDO токен к своему аккаунту для повышения уровня безопасности в будущем. Информация о браузере пользователя сообщит сайту, что пользователь имеет FIDO токен, а также сообщит сайту тип токена. Если сайт поддерживает FIDO, он в фоновом режиме опросит плагин о токене. В зависимости от политики, сайт будет предлагать пользователю подключить FIDO токен к своему аккаунту.
Порядок действий может отличаться в зависимости от типа Аутентификатора пользователя, но все типы будут поддерживаться через один и тот же плагин.
Сканер отпечатков: пользователь проводит пальцем по датчику. Аутентификатор выполняет криптооперации, данные поступают в DSM, а затем в плагин браузера.
Защищенные паролем токены: пользователь вводит правильный пароль для токена.
Уникальный идентификатор устройства: Так как это не Authentication tokens, от пользователя требуется только нажать кнопку ОК для подключения идентификатора.
Когда пользователь соглашается подключить токен и аутентифицируется на нем (при необходимости), глобальный ID токена и ID пользователя шифруются и отправляются обратно на сайт. Сайт использует Validation Cache для проверки токена. После проверки токена, сайт привязывает уникальный ID токена к аккаунту пользователя для дальнейшего использования.
Аутентификация пользователя
После того как пользователь привязал свой Токен к аккаунту он может использовать его вместо логина и пароля учетной записи. Ниже приведены три примера, но в перспективе FIDO будет поддерживать более широкий спектр FIDO токенов.
Считыватель отпечатков пальцев
Пользователь переходит на веб-сайте, его аккаунт привязан к токену со считывателем отпечатков пальцев.
Браузер сообщает сайту, что пользователь имеет FIDO токен со считывателем отпечатков для аутентификации, веб-сайт представляет пользователю вариант страницы аутентификации, поддерживающий FIDO. Веб-сайт может показать сообщение «Сканируйте палец для входа FIDO» Пользователь сканирует свои отпечатки. FIDO токен распознает пользователя. Биометрические данные пользователя никогда не покидает считыватель. Глобальный ID и аутентификационные данные шифруются и отправляется обратно на сайт через DSM и плагин.
Сайт проверяет полученные данные через Validation Cache. Веб-сайт определяет пользователя на основании глобального уникального идентификатора и идентификатора пользователя. Таким образом, обеспечивается двухфакторная аутентификацию, так как наличие токена со считывателем у пользователя является первым фактором и прохождение биометрической аутентификации является вторым фактором.
Если пользователь использовал токен со считывателем отпечатков, более чем с одной учетной записью, сайт будет запрашивать у пользователя имя аккаунта, к которому он хочет получить доступ.
Защищенные паролем токены
Пользователь переходит на веб-сайт, его аккаунт связан с защищенным паролем токеном. Это может быть USB токен или установленный на материнской плате модуль(TPM). Браузер сообщает сайту, что пользователь имеет FIDO токен с паролем, веб-сайт настраивает страницу аутентификации по технологии FIDO. Веб-сайт может представить пользователю сообщение «Нажмите здесь для безопасного входа с FIDO».
Когда пользователь нажимает на кнопку «FIDO Логин», плагин отображает локальное окно (не окно браузера) для ввода пароля токена. Этот пароль для локальной аутентификации в FIDO токене. Этот пароль не доступен через веб-браузер и должен быть передан только в токен.
FIDO токен аутентифицирует пользователя. Глобальный ID и аутентификационные данные шифруются и отправляется обратно на сайт через DSM и плагин.
Сайт проверяет полученные данные через Validation Cache. Веб-сайт определяет пользователя на основании глобального уникального идентификатора и идентификатор пользователя. Таким образом, обеспечивается двухфакторная аутентификация, так как наличие токена у пользователя является первым фактором, а знание пароля от токена является вторым фактором. Если пользователь использовал токен, более чем с одной учетной записью, сайт будет запрашивать у пользователя имя аккаунта, к которому он хочет получить доступ.
Идентификаторы
Пользователь переходит на веб-сайт, его аккаунт связан с Identification token. Это может быть встроенное аппаратное средство, дополнительные программные или аппаратные решения, которые не требуют знания PIN кода или пароля, так как они обеспечивают только идентификацию. Браузер сообщает сайту, что пользователь имеет Identification token, доступный для проверки подлинности. Веб-сайт будет запрашивать у плагина идентификационные данные. Обмен данными с сервером происходит в фоновом режиме, без взаимодействия с пользователем. Глобальный ID Identification token шифруются и отправляется обратно на сайт через DSM и плагин.
Сайт проверяет полученные данные через Validation Cache. Веб-сайт определяет пользователя на основании глобального уникального идентификатора. Если есть только одна учетная запись, связанная с идентификатором, то пользователь входит в свою учетную запись без пароля. Данный тип аутентификации является однофакторным, так как для аутентификации достаточно только владеть идентификатором.
Если политика сайта требует двухфакторную аутентификация, то от пользователя может потребоваться ввести свой пароль. В качестве второго фактора, без дополнительного взаимодействия с пользователем, проверяется наличие Identification token.
Новые типы Аутентификаторов
Одной из целей FIDO является расширение спектра устройств. Намерение состоит в том, чтобы все устройства безопасности, которые соответствуют интерфейсу FIDO плагина, должны быть доступны для всех веб-сайтов без изменения кода. Это позволит легко подключать к системе новые типы токенов.
Чтобы добавить новый тип аутентификации разработчик должен создать устройство, DSM и протестировать его с плагином. Затем разработчик должен передать в FIDO Repository данные, необходимые для проверки новых устройств. Repository будет гарантировать, что данные будут доступны всем Validation Cache проверяющих сторон.
Когда новый аутентификатор появляется на сайте в первый раз, сайт будет проверять аутентификатор с помощью Validation Cache. Веб-сайт может попросить пользователя выполнить какие-либо дополнительные действия для аутентификации пользователя, не зная подробностей этих действий, так как взаимодействие происходит через плагин и DSM. Когда пользователь выполнит необходимые действия, идентификационные данные будут подключены к учетной записи пользователя.
- FIDO альянс
- аутентификация пользователей
- двухфакторная аутентификация
- безопасность
- Информационная безопасность
- IT-стандарты
Новый стандарт для онлайн-платежей: SPC

В июне 2023 года консорциум W3C анонсировал новый стандарт для подтверждения финансовых операций Secure Payment Confirmation (SPC), который в случае принятия упростит платежи в интернете. Пока стандарт опубликован в качестве рекомендации-кандидата (Candidate Recommendation).
SPC делает стандартом для финансовых транзакций браузерную криптографию Web Authentication (WebAuthn). Это платежи по отпечатку пальца/скану лица/пинкоду и т. д. Теперь вместо кода или SMS для подтверждения транзакции 2FA можно предъявлять отпечаток пальца.
Новый стандарт должен упростить аутентификацию пользователей, обеспечить строгую аутентификацию клиента (SCA) и получение криптографического доказательства согласия. Наличие криптографического доказательства — важный аспект нормативных требований и регуляций в разных странах, в том числе Директивы о платёжных услугах (PSD2) в Европе.
В целом SPC полагается на технологию WebAuthn и работает примерно по такому же механизму, как представленный недавно стандарт беспарольной аутентификации Google Passkeys (ключи доступа), который позволяет войти в аккаунт без пароля, а по пальцу, лицу, локальному пинкоду или аппаратному ключу. То есть авторизоваться в тем же методом, каким пользователь авторизуется в операционной системе. Это считается достаточным криптографическим доказательством согласия и для аутентификации на удалённом сервере, и для платежа.
Как мы упоминали в недавней статье про Passkeys, сканирование отпечатка пальца — это самый простой и безопасный метод аутентификации, согласно опросам пользователей:

Источник: «Мультимодальная аутентификация пользователей в „умных“ средах: Исследование отношения пользователей»
Сканер отпечатка пальца и/или лица присутствует в большинстве современных смартфонов.

Принятие SPC в качестве рекомендации-кандидата указывает на то, что набор функций «является стабильным и получил широкое рассмотрение», сказано в пресс-релизе W3C. Теперь консорциум должен получить дополнительные примеры экспериментального внедрения SPC, прежде чем внести окончательные правки и принять финальную версию стандарта.
W3C отмечает актуальность нового стандарта в связи с широким распространением электронной коммерции и усилением требований к защите платежей. Если в 90-е годы для платежа было достаточно ввести номер кредитной карты в форму с POST-запросом, то сейчас это редкость. Более того, в Европе и других странах такой метод запретили законодательно, введя обязательную многофакторную аутентификацию для некоторых видов платежей. Вот здесь и возникает проблема.
Хотя многофакторная аутентификация снижает уровень мошенничества, она затрудняет процедуру платежа и увеличивает количество отказов от совершения сделки (например, см. результаты эксперимента Microsoft по использованию SCA в рамках PSD2):

В 2019 году рабочая группа W3C по веб-платежам начала работу над безопасным стандартом подтверждением платежа, который обеспечит строгую аутентификацию клиента (SCA), но будет проще в использовании. Компания Stripe осуществила пилотный проект SPC и в марте 2020 года. В эксперименте Stripe после обычной транзакции пользователю предлагается проводить будущие платежи по отпечатку пальца:

Затем браузер проверяет соответствующие криптографические примитивы:

На этом процедура завершена:

В следующий раз после ввода данных карты браузер предлагает подтвердить перевод отпечатком пальца:

После проверки в браузере платёж завершается.
По сравнению с одноразовыми паролями (OTP) аутентификация SPC увеличила конверсию на 8% и ускорила процедуру аутентификации втрое: с 36 до 12 секунд.
SPC разработан при участии группы по созданию спецификаций для безопасности платежей Web Payment Security Interest Group, куда входят W3C, FIDO Alliance и EMVCo. В результате новый стандарт совместим с актуальными протоколами двухфакторной аутентификации EMV 3-D Secure (версия 2.3) и EMV Secure Remote Commerce (версия 1.3).
Поддержка технологии SPC требует внесения изменений в браузеры для реализации WebAuthn. В настоящее время она доступна в браузерах Chrome и Edge на платформах macOS, Windows и Android. Рабочая группа W3C по веб-платежам будет способствовать внедрению этой технологии в других браузерах.
Сейчас W3C наблюдает за проведением других пилотных программ, включая второй эксперимент Stripe. Результаты ожидают к сентябрю 2023 г. После этого возможна окончательная стандартизация.

Предполагается, что платежи по SPC станут удобнее для всех. Для пользователей это более простой способ оплаты, а для мерчантов — увеличение конверсии.
- онлайн-платежи
- биометрия
- строгая аутентификация клиента
- SCA
- доказательство согласия
- Директива о платёжных услугах
- PSD2
- Web Authentication
- WebAuthn
Fido подтверждение платежа что это
Иван Осокин
Оцените автора
Добавить комментарий Отменить ответ
Свежие записи
- Холодильник Димрота для самогонного аппарата: что это такое, как выбрать?
- RCS-сообщения: что это такое, как отключить?
- Креп: что это за еда, рецепты и фото
- Египет – самые удивительные достопримечательности и места для посещения
- Пришло письмо из соцзащиты: что это означает?
Вам также может понравиться
Металлические уличные скамейки – это неотъемлемая
Аль Сафа – один из самых престижных районов Дубая
В мире, где информации становится все больше, необходимо
Петербургский рынок аренды офисных помещений — это
Видеонаблюдение и СКУД постепенно отходят на второй план.
Любые современные моющие средства, будь то стиральный

Возможно, кто-то уже слышал подобного рода сокращение.

Многим пользователям компании Ростелеком интересно