За что не любят CVV и 3D Secure. И почему разработчик не виноват. Разбор

Случай с белорусским приложением О!плати, которое позволило нам провести платежи c неправильным CVV и без 3D Secure, породил много вопросов — как о работе конкретного сервиса, так и вообще о том, как устроена защита интернет-платежей. Комментарий относительно О!плати готовит сейчас банк-эквайер Белинвестбанк. С теоретическими вопросами dev.by обратился к основателю и директору по развитию бизнеса ООО «ИКомЧардж» Александру Михайловскому. Его компания известна в Беларуси как сервис приёма онлайн-платежей bePaid.

17 комментариев
За что не любят CVV и 3D Secure. И почему разработчик не виноват. Разбор

Случай с белорусским приложением О!плати, которое позволило нам провести платежи c неправильным CVV и без 3D Secure, породил много вопросов — как о работе конкретного сервиса, так и вообще о том, как устроена защита интернет-платежей. Комментарий относительно О!плати готовит сейчас банк-эквайер Белинвестбанк. С теоретическими вопросами dev.by обратился к основателю и директору по развитию бизнеса ООО «ИКомЧардж» Александру Михайловскому. Его компания известна в Беларуси как сервис приёма онлайн-платежей bePaid.

О неправильном CVV: а был ли код?

Александр, давайте начнём с азов: что такое CVV и зачем нужна его валидация?

CVV (card verification value) — название кода у Visa, СVC (card verification code) — название аналогичного кода у Mastercard, это дополнительная мера безопасности при приеме CNP-транзакций (card not present). Платёж в интернете — это пример CNP-транзакции. 

Как и в случае с PIN-кодом, предполагается, что CVV/CVC известен только держателю карты. 

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

Валидация CVV/CVC обязательна?

Нет. Наличие этого кода не является обязательным условием для проведения CNP-транзакции.

Как вообще происходит валидация CVV/CVC? От чего она зависит — от разработчика, от банка-эквайера, от платежной системы?

От разработчика необходимость валидировать CVV/CVC вообще никак не зависит: разработчик делает то, что ему говорит заказчик. Валидация CVV/CVC зависит от конкретной ситуации, в которой формируется транзакционный запрос от эквайера к эмитенту.

Международные платёжные системы (МПС), заинтересованные в снижении мошеннических транзакций, настоятельно рекомендуют мерчантам запрашивать CVV/CVC у своих клиентов. И как правило, эквайеры требуют от мерчантов эти рекомендации выполнять.

Вместе с тем бывают ситуации, когда CVV/CVC не запрашивается и не передается — например, при рекуррентных (повторяющихся) платежах. И вообще говоря, если эквайер решит не передавать CVV/CVC в запросе эмитенту, ничто не помешает ему это сделать. Если же CVV/CVC был запрошен и передан, эмитент в своём ответе сообщает эквайеру, совпал ли переданный CVV/CVC с оригинальным кодом или нет. И это исключительное право эмитента решать, одобрять ли платёж, если CVV/CVC не совпадает. 

Почему некоторые сервисы не проверяют CVV? Может, это дорого или сложно в разработке?

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

Если эмитент имеет возможность другими способами убедиться в том, что транзакция инициирована держателем карты, то ни CVV/CVC, ни 3D Secure ему не нужны.

А как ещё эмитент может убедиться, если не с помощью CVV/CVC и 3D Secure?

Бывают ситуации, когда эквайер и эмитент — это один и тот же банк, который к тому же проводит идентификацию клиента. Например, в О!плати при регистрации кошелька пользователь проходит идентификацию, следовательно, Белинвестбанк знает, что Иван Иванов, зарегистрировавшийся в приложении — это действительно Иван Иванов. Далее, если Иван Иванов пытается пополнить свой счет в О!плати картой Белинвестбанка, последний и без CVV/CVC и 3D Secure может проверить, действительно ли именно эта карта была выдана им Ивану Иванову.

Да, в такой ситуации отсутствие проверки понятно. Но в случае с О!плати платежи проходили без проверки CVV c карт других банков. Как такое может быть? Белорусские банки-эмитенты не запрашивают CVV/CVC?

Сложно сказать, этот вопрос надо адресовать банкам-эмитентам. Я могу сказать только одно: CVV/CVC известен лишь эмитенту, ни эквайер, ни разработчик ничего о нём не знает. Задача разработчика — принять код от клиента и отправить его на шлюз эквайера. Задача эквайера — сформировать запрос по протоколам Visa и Mastercard и передать в сети МПС. А уже эмитент, знающий, какой CVV/CVC на самом деле, даёт ответ: совпали цифры или нет. Почему проходят платежи с неправильными CVV/CVC? У меня две версии. Либо эмитент разрешил транзакции с неправильными CVV/CVC, и тогда это на совести эмитента. Либо эквайер CVV/CVC не отправляет.

(Вторая догадка Александра оказалась правильной. Наш сотрудник обратился в банк-эмитент карты, участвовавшей в тестировании, с вопросом о некорректном CVV. Пришёл такой ответ: «Банк, обслуживающий данную платформу, не передал нам поле, содержащее значение CVV-кода, введёного вами, соответственно проверки CVV-кода на нашей стороне не было. Согласно правилам международной платёжной системы, авторизовать операцию, мы как эмитент можем и без CVV-кода. По этой причине операция прошла успешно»). 

А какая выгода эквайеру не передавать CVV?

Это может быть забота об удобстве плательщиков. Приём платежей в электронной коммерции — это вечный поиск баланса между защитой информации и удобством для клиентов. Например, во многих приложениях карточку можно ввести путём фотографирования — данные распознаются автоматом, но CVV/CVC в этих случаях не считается, так как он указан на обратной стороне карты. Такая практика не так уж и редка. Например, магазин Amazon тоже не запрашивает CVV/CVC — у них просто нет такого поля.

Но тут-то поле есть. И я всё равно ввожу код!

Можно предположить, что в целях упрощения платежей эквайер отказался от CVV/CVC, но разработчики не успели убрать это поле: оно есть, но данные никуда не передаются. Но это всего лишь моё предположение. Точный ответ знает только Белинвестбанк.

А почему эмитенты не отклоняют транзакции без CVV?

Трудно сказать. Для эмитентов тоже важно найти баланс между защитой своих клиентов от мошенничества и удобством карточных платежей для них же. CVV/CVC — это один из способов верификации держателя карты. Но если этот код не передан, верифицировать нечего. Однако отсутствие кода не обязательно означает, что транзакция — мошенническая.

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

Принимая решение о том, одобрить или нет платёжную транзакцию, эмитент смотрит не только на наличие-отсутствие CVV/CVC, но и на другие параметры транзакции.

Может, это всё-таки стоит дополнительных денег?

Нет. По крайней мере, здесь нет расходов, которые бы делали экономически целесообразным отказ от CVV/CVC. Это стандартные протоколы, формированием запросов и обработкой ответов занимается специализированное ПО, которое само по себе дорогое, но CVV/CVC входит в его базовый функционал. Для разработчиков добавление поля тоже не представляет никакой сложности.

Давайте резюмируем эту часть: отсутствие валидации CVV/CVC — это нормально?

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

Как отсутствие валидации CVV влияет на безопасность платежей? А на риск мошеннических действий с картами?

Конечно же, отсутствие CVV/CVC при CNP-транзакции обычно увеличивает риск того, что кто-то заплатит не своей картой. Номер карты и срок её действия легко подсмотреть, запомнить, украсть. Увидеть CVV/CVC, которые расположены на обратной стороне карты — сложнее. Именно поэтому эмитенты, как правило, отклоняют транзакции, в которых CVV/CVC не совпадает с оригинальным.

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

О валидации имени кардхолдера: не нужна?

Отсутствие валидации имени держателя карты — это нормально?

Да, это нормально.

Имя вообще никто и никогда не проверяет?

Я могу ошибаться, но, по-моему, имя держателя обычно не проверяется. Опять же, если кто-то и может его верифицировать, то только эмитент.

А зачем тогда это поле?

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

Опять же, как и в случае с CVV/CVC, если эмитент имеет какой-то иной способ убедиться, что транзакция действительно была инициирована его клиентом, то ему всё равно, что написано в поле «имя держателя карты».

О 3D Secure: почему им пренебрегают

О чём свидетельствует отсутствие СМС с динамическим паролем? О том, что карта или сервис не подключены к 3D Secure?

СМС с OTP (one time password), по идее, должен приходить клиенту от эмитента всякий раз, когда тот проходит проверку по 3D Secure. Отсутствие такой СМС не обязательно означает неучастие карты в программе 3D Secure. У эмитента может банально сбоить сервис проверки. Или может глючить оператор мобильной связи.

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

Если ACS-сервер доступен, но СМС не приходит из-за проблем с сотовой связи, то через 15 минут сессия закрывается и транзакция автоматически считается неуспешной.

А если карта участвует в 3D Secure, но СМС не приходит и платёж при этом успешен, значит, платёжный сервис не участвует в программе?

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

Почему некоторые сервисы не подключены к 3D Secure? Это сложно, дорого? Как и между кем происходят расчёты за эту услугу?

Трудно сказать почему, в каждом конкретном случае есть своя причина. Использование 3D Secure уже стало стандартом в платёжной индустрии. Международные платёжные системы создали такие условия, когда эмитенты стремятся включить все свои карты в программу 3D Secure. Дело в том, что если карта не участвует в этой программе, то ответственность за мошеннический платеж по такой карте, согласно правилам МПС, возлагается на эмитента. А кому хочется терять деньги?

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

Эквайер как-нибудь экономит, согласившись на отказ от 3D Secure? Кто платит за СМС с подтверждающим кодом?

За СМС платит эмитент, но мне кажется, что расходы там не такие уж большие. Эквайер за счёт отказа от 3D Secure никак не экономит — более того, он рискует.

Это просто, ничего не стоит, убирает риски — в чём тогда смысл отказа от защиты?

В том, чтобы клиентам мерчанта было удобнее и приятнее делать платежи, чтобы они не зависели от СМС. Как правило, отказ разрешается крупным мерчантам — мелким мерчантам такое не позволяется. 

Для эквайера смысл в том, чтобы угодить крупному клиенту. Допустим, есть сервис, который обслуживает крупных мерчантов. Если крупный мерчант убеждается, что без 3D Secure объём платежей увеличивается на 5-10%, то он, конечно, захочет отказаться от защиты. Он подписывает допсоглашение с эквайером о том, что гарантирует покрытие всех убытков банка, связанных с мошенничеством. Если банк-эквайер ему откажет, есть вероятность, что мерчант пойдёт к другим банкам-эквайерам и весь оборот перейдёт к конкуренту. 

Так как Белинвестбанк в описанном случае является и мерчантом, и эквайером (и эмитентом для некоторых транзакций), то понятно желание банка сделать пользование кошельком простым и приятным.

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

Это обычная история, мошенники в Беларуси склонны к странным поступкам: они воруют карты, платят ими в кафе и ресторанах, потом попадаются и идут в тюрьму.

В комментарии под материалом dev.by вы выразили мнение, что отсутствие проверки  — зона ответственности банков, а не разработчика. Ответственности разработчика вообще нет?

Мы — сами разработчики и имеем опыт интеграций с сотней разных банков-эквайеров по всему миру. Разработчик делает то, что сказано в API, который он получает от эквайера. Сказано в API передавать значение CVV/CVC — разработчик будет запрашивать его у плательщика и передавать эквайеру. Но валидировать это значение может только эмитент, и никто другой. Соответственно разработчик за валидацию CVV/CVC отвечать никак не может. Решение о том, одобрять ли транзакцию с некорректным CVV/CVC, принимает эмитент. А решение о том, проводить ли такую транзакцию, принимает эквайер на основе ответа по валидации от эмитента. Так же, как и решение о том, передавать ли вообще  CVV/CVC эмитенту. Как видите, разработчик здесь ни на что не влияет.

Приложение от LWO пропускает платежи с липовыми CVV (скоро — в минских маршрутках)
Приложение от LWO пропускает платежи с липовыми CVV (скоро — в минских маршрутках)
По теме
Приложение от LWO пропускает платежи с липовыми CVV (скоро — в минских маршрутках)

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

По IP больше не вычислишь: курсы по защите данных в сети
По IP больше не вычислишь: курсы по защите данных в сети
По IP больше не вычислишь: курсы по защите данных в сети
В то время как кража и эксплуатация личных данных стали обыденностью, очень важно уметь защитить себя в Интернете. DigitalDefynd собрал 10 онлайн-курсов по кибербезопасности, которые позволят вам чувствовать себя защищенными в сети.
Как Twitter ломали через Slack
Как Twitter ломали через Slack
Как Twitter ломали через Slack
1 комментарий
Хакеры показали, как устроить транспортный коллапс с помощью светофоров
Хакеры показали, как устроить транспортный коллапс с помощью светофоров
Хакеры показали, как устроить транспортный коллапс с помощью светофоров
Пранкеры запустили порно во время слушаний по делу взломщика Twitter
Пранкеры запустили порно во время слушаний по делу взломщика Twitter
Пранкеры запустили порно во время слушаний по делу взломщика Twitter

Обсуждение

-1

После прочитанного я пришел к выводу что нал все таки надежнее чем карты ...

Дмитрий Иванов
Дмитрий Иванов ФРилансер в Global Freelance
1

Хороший тюториал как вешать лапшу на уши заказчику если что-то не работает

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
3

Разработчик не виноват? Может быть. Только вот именно bePaid виноват в том, как onliner проинтегриван с bePaid --- виноват в том, что разрешил(!) сделать такую небезопасною (для пользователя) интеграцию.

Alexander Mihailovski
Alexander Mihailovski Директор по развитию бизнеса в eComCharge LLC
1

Максим, а в чем вы видите небезопасный процесс приема платежей через Onliner Pay? Они для привязки карты 3d secure используют. Этого не достаточно?

bePaid дает мерчанту набор инструментов защиты от мошенничества. Как их использовать и использовать ли вообще - это дело самого мерчанта.

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
3

Я вижу две большие проблемы:

I. ввод данных на сайте onliner-а, а не редирект на bePaid-вский сайт --- это позволяет (теоретически) программистам onliner собирать данные моей кредитной карты

я не защищён от того, что для некоторого IP, или для каждого k-того ввода данных карты сайт покажет мне точно такую же форму, но работать она будет иначе --- будет данные моей карты копировать в сторонку

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

Alexander Mihailovski
Alexander Mihailovski Директор по развитию бизнеса в eComCharge LLC
2

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

Открытие платежной формы в айфрейме - это очень распространенная практика. Считается, что отсутствие редиректа покупателя на платежную страницу размещенную на сервере компании-поставщика платежных услуг увеличивает конверсию в интернет-магазине. Поэтому сейчас все платежные провайдеры предлагают своим клиентам на выбор платежную страницу в айфрейме или с редиректом. Но и тот, и другой вариант одинаково защищает карточные данные покупателей в соответствии с требованием индустриального стандарта PCI DSS.

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

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

II. Максим, у вас ведь наверняка есть смартфон. И наверняка к вашему аккаунту в Google или Apple привязана карта, не так ли? Вы же не беспокоитесь о том, что кто-то в Google или Apple может снять ваши деньги и уехать? А вас не беспокоит, что кто-то из банка в котором у вас открыта ваша зарплатная карта может снять ваши деньги с картсчета и пуститься в бега? Или кто-то из компании вашего мобильного оператора может вывести деньги с вашего баланса (если вы пользуетесь услугами по предоплате) и тоже исчезнуть?

Теоретически и технически такое возможно. Но давайте все же включим здравый смысл. Вероятность совершения такого события очень низка. И если такое вдруг произойдет, вы можете опротестовать платеж, совершенный без вашего разрешения и вернуть украденные деньги. Процедура возврата для таких случаев регламентирована правилами МПС.

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

2

Мне кажется Вы недооцениваете способность читателей dev.by к логическому мышлению. Вы пишете, что защитой от фишинга МОЖЕТ быть внимательность. И, действительно, современные браузеры предоставляют внимательному пользователю инструменты, которые помогают выявить фишинговый сайт. При должном уровне внимательности и здоровой паранойи, это, практически, всегда возможно. Особенно после того, как стало невозможным скрывать адресную строку (и «рисовать» её муляж, который мог эмитировать даже окна проверки сертификатов).
Отображая форму ввода в iframe вы оставляете только один способ защититься от потенциальной недобросовестности онлайнера - внимательный анализ исходного кода. Логика тут может быть в том, что вы считаете что уровень доверия онлайнеру и bePaid одинаково низкий (хотя у меня, например уровень доверия к bePaid в вопросе защиты персональных данных выше чем к онлайнеру), но все равно выбранный вами подход теоретически менее надежен, так как создает дополнительный вектор атаки.
Безопасность (в обсуждаемом контексте) в конечном итоге сводится к доверию. Сравнивать доверие к bePaid и onliner с доверием к google и apple, на мой взгляд очень амбициозно.
Пример с банком и опсосв, особенно некорректен, так как в этом случае, дополнительным поставщиком доверия выступает государство, которое в свою очередь контролирует деятельность банков и опсосв при помощи регулярных аудитов.

Демагогические приемы типа «давайте включим здравый смысл» «вероятность крайне низка» оставлю без комментариев.

Alexander Mihailovski
Alexander Mihailovski Директор по развитию бизнеса в eComCharge LLC
0

Юрий, мы даем каждому клиенту выбор: использовать айфрейм или использовать редирект к нам. А если клиент сертифицирован по PCI DSS, мы готовы дать ему host-to-host интеграцию для того, что бы он использовал полностью свою платежную форму. Ограничивать клиента в этом выборе - это не правильно. А предоставлять такой выбор - это нормальная мировая практика.

Что касается сравнения доверия к bePaid и к Google или Apple, объективно сохранность платежных данных и безопасное обращение с ними и у нас и у них - одинаковое. Потому что мы все работаем по одним и тем же стандартам, правилам и регламентам. И мы все проходим один и тот же регулярный аудит по PCI DSS, регулярное тестирование на проникновение.

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

Ваше заявление о сознательном снижении уровня защиты пользователя при отображении платежной формы в айфрейм базируется на том, что айфрейм подделать легче, чем редирект на фейковую страницу. А обнаружить фальшивость айфрейма - сложнее. Эти 2 утверждения сами по себе - верные. Но если вы исходите из того, что некий гипотетический злоумышленник может устроить подмену айфрейма с целью воровства платежных данных, как использование редиректа на платежную страницу остановит этого злоумышленника? Что мешает злоумышленнику, если он уже имеет доступ к коду сайта, добавить скрипт, который для определенных IP адресов или каждой энной попытки будет отображать поддельный айфрейм для сбора данных, а во всех остальных случаях запускать легитимный редирект на платежную страницу?

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
0

Что мешает злоумышленнику, если он уже имеет доступ к коду сайта, добавить скрипт, который для определенных IP адресов или каждой энной попытки будет отображать поддельный айфрейм для сбора данных, а во всех остальных случаях запускать легитимный редирект на платежную страницу?

Полный запрет на работу через iframe-ы таких сервисов как bePaid и остальных. Именно это и защитит. Пользователи привыкнут/будут знать, что данные карт НИКОГДА не надо вводить в iframe-ах.

Точно так же как научились/учаться не передавать карту в руки кассиру.

Именно из-за того, что защита на уровне таких сервисов как bePaid в среднем плохая, и есть куча таких проблем, в Европе активно все готовятся к внедрению обязательного 3D Secure 2.

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
3

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

onliner у меня ОТБИРАЕТ эту возможность, если бы был redirect на сайт:

я бы мог проверить ssl мог бы проверить hostname современные браузеры имеют базы фишинговых сайтов я бы платил через сайт много раз, и мой браузер бы помнил все эти данные

Вводите данные своей карты только на том ресурсе, которому вы доверяете. К осторожности и осмотрительности призывают все: и банки, и bePaid в своих статьях, и МПСы.

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

При чем здесь bePaid или любой другой поставщик платежных услуг?

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

Но давайте все же включим здравый смысл.

Да, давайте включим. Одно дело, apple, google, сотрудник банка, ... полный список будет этак 10 крупных компаний и банков. Причём все они сертифицированы по PCI DSS и тд и тп.

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

Идивительно дело, в СМИ выходят статьи о звонах машенников которые "откуда-то" знают данные карты, имя, телефон... а у нас почти С КАЖДОГО мелком сайте программист/admin/хакер-"взломавший"-сервер может украсть данные карты.

===============

Считается, что отсутствие редиректа покупателя на платежную страницу размещенную на сервере компании-поставщика платежных услуг увеличивает конверсию в интернет-магазине.

А вот это правда. Правда правда не том, что увеличивает, а в том, что так считается. К черту разговоры про security, всё дело в деньгах.

При этом, это "считается" на самое деле не совсем правда --- стилизованные(! это когда платёжный агрегатор рисует форму ввода данных в дизайне того, кто запросил --- обычно просто custom-ная css и img) платёжные формы работает не хуже, а может даже лучше.

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
3

Например, вот как принимают деньги некоторые: https://imgur.com/qdy7M1C pay.alfabank.ru для конкретного merchanta-а рисует красивую форму, а пользователю не надо доверять данные абы кому.

Alexander Mihailovski
Alexander Mihailovski Директор по развитию бизнеса в eComCharge LLC
0

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

Если уж говорить по PCI DSS, bePaid тоже сертифицирован по PCI DSS Level 1. Это наивысший уровень сертификации. Без него мы не имели бы права обращаться с карточными данными. Мы ежегодно проходим сертификацию и ежеквартально тесты на взлом нашей системы и проникновения. Процедуры и требования одинаковы для всех. Что для нас, что для крупного банка, что для международной корпорации.

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

bePaid тоже предлагает кастомизацию редиректой платежной страницы. Те из мерчантов, которые хотят ее кастомизировать, это делают. А те кто хотят использовать платежный виджет в айфреме - использую его. Повторюсь, - это право мерчанта выбирать, какой вариант ему больше нравится. В приведенном вами примере компания, в которой вы работаете, решила использовать редирект на платежную старницу эквайера. Это право компании. Но если бы ваша компания имела PCI DSS сертификат и решила бы использовать полностью собственную платежную платежную страницу, ваш эквайер бы не отказал.

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
2

bePaid сертифицирован, вопросов нет --- молодцы, это ваш бизнес и всё такое

onliner.by --- нет ; я понимаю что "через iframe разрешено" это недостаток самой PCI DSS сертификации, точнее пример того, что это не более чем бюрократическая процедура

при прохождении PCI DSS сертификации, вы же прямо списки людей составляли которые теоретически могут получить доступ к данным карты, а тут многие кто к вам подключён --- тоже могут, но ... типа не приделах

Более того, я готов поспорить, что ответственные менеджеры со стороны onliner НЕ ВКУРСЕ , что их программисты/админы могут украсть данные карты ; вы их не проинформировали, и их программисты им об этом не сказали.

В целом искреннее Спасибо, что вы признаете теоретическую возможность у их получить данные карт. У меня негативный опыт общения с некоторыми белорусскими ресурсами/приложениями, там люди утверждали что нет возможности украсть данные даже теоретически => что собственно и вызывает у меня понимания того, что у людей просто недостаточно квалификации, а значит риск утери данных ещё больше

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

Alexander Mihailovski
Alexander Mihailovski Директор по развитию бизнеса в eComCharge LLC
0

Максим, прием платежей через платежную форму в iframe - это не недостаток. Это просто еще один способ отображения платежной формы покупателю. Повторюсь, платежная форма в iframe грузится с нашего сервера, не со стороны Онлайнера. Данные, введенные на этой платежной форме сразу шифруются и отправляются на наш сервер, без передачи на сервера Онлайнера. Все строго в соответствии с принятыми стандартами безопасности при работе с карточными данными.

Единственная возможность у программистов и админов Онлайнера или вообще говоря любого другого интернет-ресурса собрать и похитить платежные данные посетителей - это создать и разместить на сайте фальшивую платежную форму для сбора нужных данных. Но эта возможность совершенно никак не зависит от того, каким образом Онлайнер или любой другой интернет-ресурс подключен к bePaid или другому поставщику платежных услуг, каким образом он принимает платежи по картам и принимает ли он их вообще.

Кассир в любом магазине сегодня может увидеть, запомнить или записать номер банковской карты покупателя и срок ее действия, а потом попытаться использовать ее для оплаты чего-либо через интернет. А до перехода банков на карты с чипами кассир в любом магазине или ресторане имел прекрасную возможность поставить скиммер на терминал что бы сделать дамп данных с магнитной полосы карты покупателя, создавать ее клон и использовать его хоть для покупок, хоть для снятия наличных в банкомате. Собственно еще лет 5 назад большинство дампов для создания клонов карт поставлялись на черный рынок именно из таких источников. И следуя вашей логике, можно обвинить банк-эквайер, поставщика и даже производителя POS терминалов в том, что предоставив магазину возможность принимать к оплате карты через торговый эквайринг, они тем самым создали возможность для нечестного на руку сотрудника магазина украсть карточные данные покупателя. Но ведь это будет абсурд, верно? Да, такая возможность теоретически существует. Но это не означает что торговый эквайринг - зло и от него нужно отказаться.

Максим Мельников
Максим Мельников Developer в Wargaming / Гейм Стрим
1

(у комментария в 23 июня 2020, 21:18 почему-то нет кнопки "ответить")

Максим, прием платежей через платежную форму в iframe - это не недостаток.

Именно что недостаток. Недостаток для меня как для пользователя --- я не доверяю onliner-у, а bePaid-у доверяю. Знаете почему? потому что вы прошли сертификации PCI DSS, а они НЕТ!

Повторюсь, платежная форма в iframe грузится с нашего сервера, не со стороны Онлайнера.

Вы в это верите, вы этого не знаете. Вообще не факт, что мы с вами видим одинаковые сайты. Может идёт A/B тестирования, и мы видим разные версии, с разной реализацией платежных методов.

Все строго в соответствии с принятыми стандартами безопасности при работе с карточными данными.

Увы нет, раз onliner может (даже только теоретически) украсть данные моей карты, то какая тут безопасность?!

Данные, введенные на этой платежной форме сразу шифруются и отправляются на наш сервер, без передачи на сервера Онлайнера.

В ваш сервис данные отправляются напрямую, а рядом может быть JS который ТОЖЕ собирает и ТОЖЕ отправляет мои данные, но уже в другую сторону.

Все строго в соответствии с принятыми стандартами безопасности при работе с карточными данными.

Только что попробовал ввести неправильный CCV2 , и знаете что случилось?! Ему пофиг, меня отпрвило на форму ввода 3D-Secure-е. Дальше проверять не стал :(

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

Не просто может, но и делает. И таких случаев много. Именно по этому современная рекомендация: 1) не давать карту в руки кассиру ; 2) не показывать её ; 3) отвернуть терминал от кассира ; 4) банки запрещают видеосъемку данных карты.

Т.е. проблема есть, она признана, и с ней боряться.

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

Да, ещё один отличный пример, того, что иногда надо сделать менее удобно (просить вводить pin код), для обеспечения безопасности.

Собственно еще лет 5 назад большинство дампов для создания клонов карт поставлялись на черный рынок именно из таких источников.

Да, а теперь основной источник такие вот "левые" сайты НЕ сертифицированные по PCI DSS, которые встроили платёжные форму через iframe и КОПИРУЮТ эти данные на сторону.

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

Да, можно и даже нужно.

Но ведь это будет абсурд, верно?

Никакой ни абсурд, именно из-за таких обвинений и расследований инцидентов и случился переход на чип-карты. Потому что старый способ был НЕ БЕЗОПАСНЫМ и на его жаловались, т.е. обвинения были СПРАВЕДЛИВЫМИ.

Единственная возможность у программистов и админов Онлайнера или вообще говоря любого другого интернет-ресурса собрать и похитить платежные данные посетителей - это создать и разместить на сайте фальшивую платежную форму для сбора нужных данных.

Да, только вы расписываете будто это как-то сложно. А тут работы на пару часов.

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

А вот тут неправда. Вы можете запретить onliner-у, и не только ему, а вообще всем делать оплату через iframe. И заставить его делать через redirect на сайт bePaid. Что это даст:

a) пользователи привыкнут, что должен быть редирект, и будут удивляться/будут внимательны если вдруг случилось что-то не так

b) пользовательские браузеры запомнят куки и прочее для сайта bePaid , и если вдруг будет другой сайт (который выглядят так же), то удивяться что что-то не так ---- точно так же, как я удивляюсь и перепроверяю URL, когда вдруг мне надо вводить login&password в gmail / youtube / etc, я знаю что я там залогинен --- а раз просят ввести, то это похоже на фишинговый сайт

c) сайт bePaid сможет запомнить данные карты , в том числе куки, автодополнения и тд --- пользователям НЕ НАДО будет вводить данные карты => а это плюс к удобству и плюс к безопасности

d) если я введу данные на левом сайте, данные мои скопируют, но платёж мой не пройдёт --- ведь единственный способ оплаты, это через сайт bePaid (никаких iframe-ов, API и тд)

ИМЕННО в этом я вас и обвиняю! Вы разрешаете(!) вашим клиентам использовать технологии уровня "чековые книжки" и "банковские карты без чипа". Все эти способы проигрывают!!! по безопасности вариант вводу данных на сайте bePaid.

3

Написали бы прямо: мы обменяли немножко conversion rate на немножко безопасности, такова жизнь, отнеситесь с пониманием. Это было бы достойно, а не пытаться нас убеждать в том, во что сами не верите.

Позволю себе анекдот:
Звонок провайдеру.

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

Alexander Mihailovski
Alexander Mihailovski Директор по развитию бизнеса в eComCharge LLC
0

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

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже