Comments 16
Для UWP бы еще запилили.
0
Вопрос1. Банки как-то планируют (или уже) стилизуют свой 3D-secure странички под мобильные устройства, например, сматрфоны или к примеру можно отправлять зарпос на открытие именно 3D secure под мобильные устройства (сейчас не всегда удобно).
Вопрос2 (более общий). Сейчас бывает так, что карта привязывается к SIM карте, есть ли уже что-то рабочее которое позволяет «взять данные» с SIM без необходимости ввода данных о карте?
Вопрос2 (более общий). Сейчас бывает так, что карта привязывается к SIM карте, есть ли уже что-то рабочее которое позволяет «взять данные» с SIM без необходимости ввода данных о карте?
0
Вопрос1.
select count(distinct name) from allbanks
count
--------
12703
вот столько у меня в базе банков по всем странам
как вы думаете, смогут все банки в едином порыве адаптировать свои 3DS страницы? я думаю эту проблему не побороть с учетом сколько банков в мире технологически отсталые, 3DS должен умереть сам с распостранением мобильных технологий или трансформироваться в новый стандарт. Сейчас с ним много проблем: TLS 1.2 обязателен для iOS но поддерживается не всеми банками, а если банк принудительно переходит на TLS 1.2, то у Android версии <4.3 начинаются свои проблемы
Вопрос2 (более общий).
Протокол 3DSecure устарел еще до того, как его начали банки использовать массово, к тому же он разрабатывался без расчета на мобильные устройства вообще. Если какой-нибудь крупный игрок на рынке, например Apple или Google предложит Visa/MasterCard свой стандарт, то есть шанс, что 3DSecure привяжется к устройству или sim, но я думаю что это маловероятно
0
Благодарю за развернутый ответ. Я думал конечно не самим банкам менять, разработчикам ихнего ПО. Но не знаю так хорошо внутрянку, так что не буду утверждать.
По вопросу2, вот пример из жизни — хочу заказать пиццы и оплатить в мобильном приложении сразу (так как у курьера нет терминала к примеру), то пока придется работать с тем чем есть… 3d secure же?
По вопросу2, вот пример из жизни — хочу заказать пиццы и оплатить в мобильном приложении сразу (так как у курьера нет терминала к примеру), то пока придется работать с тем чем есть… 3d secure же?
-1
3ds можно использовать опционально, если риск мошенничества небольшой, к тому же есть физический адрес получателя услуги, то 3ds лучше не использовать — это право магазина/банка-эквайера
0
Про разработчиков вы в целом правы, банки эмитенты для 3-d secure как правило используют готовое решение, которое предоставил им вендор процессингового ПО. И поменять на странице ввода пароля они могут разве что только картинки с логотипом банка.
Сама же страница описана в спецификации протокола, есть даже расширение спецификации для мобильных устройств — 3-D Secure: Protocol Specification – Extension for Mobile Internet Device, но, либо соответствующий функционал не реализован вендором, либо банк не настроил…
Сама же страница описана в спецификации протокола, есть даже расширение спецификации для мобильных устройств — 3-D Secure: Protocol Specification – Extension for Mobile Internet Device, но, либо соответствующий функционал не реализован вендором, либо банк не настроил…
0
Мне не особо понятно, что именно мешает автору приложения воспользоваться интроспекцией и утащить введённые в компонент платёжные данные себе. Схема по сути ничем не отличается от внедрения на сайт продавца HTML-формы без использования iframe. Так же мне не особо понятно, как именно вы убедили в безопасности предложенной схемы аудитора.
+1
А как вы будите аудит проходить с CloudipspWebView ? Да и где и есть подозрения, что доступ все можно получить к данным карт через дамп/рефлексия/внутреннее api?
Анекдот на новый лад
— А вот компания Х говорит, что не обрабатывает данные банковских карт
— Так и вы говорите, что не обрабатываете… :-)
Анекдот на новый лад
— А вот компания Х говорит, что не обрабатывает данные банковских карт
— Так и вы говорите, что не обрабатываете… :-)
0
так и к фрейму в браузере можно получить доступ в определенных условиях
еще можно трафик перехватить у клиента через MITM и расшифровать, если клиент не обращает внимание на предупреждения браузера
вы не поверите, но PCI DSS не гарантирует защиту данных от перехвата, дампа, вторжения, атаки
это набор требований и рекомендаций, которые минимизируют риск компроментации и определяют ответственных за возможные инциденты
еще можно трафик перехватить у клиента через MITM и расшифровать, если клиент не обращает внимание на предупреждения браузера
вы не поверите, но PCI DSS не гарантирует защиту данных от перехвата, дампа, вторжения, атаки
это набор требований и рекомендаций, которые минимизируют риск компроментации и определяют ответственных за возможные инциденты
+2
Проясните, пожалуйста, такой момент. Допустим, у меня есть интернет-магазин, я реализовал мобильное приложение (клиент к своему магазину) и вставил в него ваш SDK, чтобы принимать карты к оплате прямо в приложении. Сертифицировать по стандарту PA-DSS мое приложение мне необязательно (он носит рекомендательный характер, о чем сказано в статье). Подпадает ли это приложение под PCI DSS?
Как написано в стандарте, PCI DSS распространяется на информационные инфраструктуры организаций, которые передают, хранят и обрабатывают карточные данные. Приложение стало частью моей информационной архитектуры? Думаю, да. Передаются ли карточные данные с помощью приложения? Точно да.
Соответственно, как я понимаю, приложение попадает в scope, который подлежит сертификации и должен проверяться на аудите. Более того, в scope попадают и сами устройства (т.е. смартфоны и планшеты) всех моих клиентов (ведь то, что устройство «не ворует» данные карточки, никак не подтверждено). Если что, я имею ввиду не ваш scope, как посредника (потому что вы предоставили только лишь SDK), а scope моего магазина. Означает ли это, что использование вашего SDK в моем мобильном приложении накладывает на меня обязанность проходить дорогостоящий аудит PCI DSS?
Так вот вопрос в том, прав ли я в своих рассуждениях, а если нет, то в чем ошибка? Только укажите, пожалуйста, ссылки на выдержки из стандартов или разъяснения этих стандартов, чтобы точно развеять заблуждения.
Как написано в стандарте, PCI DSS распространяется на информационные инфраструктуры организаций, которые передают, хранят и обрабатывают карточные данные. Приложение стало частью моей информационной архитектуры? Думаю, да. Передаются ли карточные данные с помощью приложения? Точно да.
Соответственно, как я понимаю, приложение попадает в scope, который подлежит сертификации и должен проверяться на аудите. Более того, в scope попадают и сами устройства (т.е. смартфоны и планшеты) всех моих клиентов (ведь то, что устройство «не ворует» данные карточки, никак не подтверждено). Если что, я имею ввиду не ваш scope, как посредника (потому что вы предоставили только лишь SDK), а scope моего магазина. Означает ли это, что использование вашего SDK в моем мобильном приложении накладывает на меня обязанность проходить дорогостоящий аудит PCI DSS?
Так вот вопрос в том, прав ли я в своих рассуждениях, а если нет, то в чем ошибка? Только укажите, пожалуйста, ссылки на выдержки из стандартов или разъяснения этих стандартов, чтобы точно развеять заблуждения.
0
в статье я ссылаюсь пост https://habrahabr.ru/company/dataart/blog/274325/ — здесь детально затрагивается эта тема
0
В статье сказано, что мое приложение не обязано сертифицироваться по PA DSS. Но про соответствие инфраструктуры моего магазина, в которой работает такое приложение, стандарту PCI DSS и необходимости прохождения аудита ничего не сказано. Можете пояснить?
0
если ваше приложение не передает карточные данные через вашу инфрастуктуру (а для этого есть такая функциональность, как токенизация карты), то ваша инфрастуктура не попадает под scope
0
Т.е., получается, если данные карты передаются с помощью вашего SDK только вашему серверу, то приложение как бы «выпадает» из моей инфраструктуры и мне ничего сертифицировать не надо?
Тогда в чей scope попадает передача карточных данных, введенных в моем мобильном приложении? В ваш? А как вы тогда проходите аудит на соответствие PCI DSS? Вряд ли вы можете показать аудитору все приложения, использующие указанный SDK. P2PE и токенизацию в API вы не используете. На чьи плечи ложится ответственность за мошеннические транзакции по номерам карт, украденным из приложений, использующих ваш SDK?
Тогда в чей scope попадает передача карточных данных, введенных в моем мобильном приложении? В ваш? А как вы тогда проходите аудит на соответствие PCI DSS? Вряд ли вы можете показать аудитору все приложения, использующие указанный SDK. P2PE и токенизацию в API вы не используете. На чьи плечи ложится ответственность за мошеннические транзакции по номерам карт, украденным из приложений, использующих ваш SDK?
0
В область аудита PCI DSS торгово-сервисного предприятия (мерчанта), который использует мобильное приложение для оплаты картой, входит процесс разработки данного платежного приложения (6 раздел PCI DSS).
Если своей информационной инфраструктуры нет и из мобильного приложения отправляются карточные данные напрямую сертифицированному поставщику услуг эквайринга, то область аудита мерчанта будет ограничена только 6 и 12 разделами PCI DSS.
В зависимости от количества транзакций, обрабатываемых в год, мерчант должен подтвердить соответствие либо через QSA-аудит (если количество транзакций в год более 1 000 000), либо через заполнение листа самооценки (если количество транзакций в год менее 1 000 000).
описанное выше верно, если приложение:
— не хранит карточные данные на мобильном устройстве а только отправляет их сертифицированному поставщику услуг;
— приложение обрабатывает только карты одного держателя карт.
Если своей информационной инфраструктуры нет и из мобильного приложения отправляются карточные данные напрямую сертифицированному поставщику услуг эквайринга, то область аудита мерчанта будет ограничена только 6 и 12 разделами PCI DSS.
В зависимости от количества транзакций, обрабатываемых в год, мерчант должен подтвердить соответствие либо через QSA-аудит (если количество транзакций в год более 1 000 000), либо через заполнение листа самооценки (если количество транзакций в год менее 1 000 000).
описанное выше верно, если приложение:
— не хранит карточные данные на мобильном устройстве а только отправляет их сертифицированному поставщику услуг;
— приложение обрабатывает только карты одного держателя карт.
0
Sign up to leave a comment.
Встраиваем прием платежей в мобильное приложение, или почему можно забыть про PCI DSS и PA DSS