«основная задача продавщицы - подавать водку и хлеб с полки, больше она покупателю ничего не должна, тем более улыбаться, быть вежливой, предложить еще что-то или про акцию напомнить»
Думаю, понимаю, куда Вы клоните, а потому такая наивность поражает. Ущерб для банка или ПС — это ущерб, в конечном итоге, для владельцов карт. Вы думаете, кто этот ущерб возмещает? В комиссии ПС и банков закладывается это ущерб, и затраты на risk mitigation и т. п.
чтобы не засорять ветку, напишите в ЛС, пришлите инфу на API пос-терминала, на который вы ссылались выше, и как вам удалось сэмулировать банковскую карту, т. к. chameleon (на который вы ссылаетесь), насколько помню, банковские карты эмулировать не умеет (могу ошибаться).
Я в ответ пришлю инфу по аутентификации банковских карт
Вы говорите о какой-то системе, сделанной на коленке и неправильно. Как написал ниже, таких разработчиков надо гнать взашей. Если они не проводят аутентификацию карты — это значит, что они нарушили кучу требований. Но мне что-то подсказывает, что кто-то фантазирует. Или кто-то с нарушениями проводит CNP транзакции.
А кто разработчик системы в Красноярске? К ним появились вопросы.
Вероятно, Вам самим нужно вылезти из танка. Если в Вашей системе Вы ничего не проверяете — это основание для инициирования проверки на соответствие требованиям ПС.
Судя по вашему профилю, я занимаюсь платежными системами почти столько же, сколько Вам лет.
Поэтому рекомендую изучить, что такое аутентификация карты и что такое авторизация.
Кстати, на хабре много статей писали на эту тему.
А то по вашей логике, я могу взять, в любую Java карту запихнуть в EF pan в нужном формате и по ней проехать? Смешно.
Надеюсь, как изучите вопрос, Вам хватит мужества извиниться.
Всем остальным объясняю: на любой банковской карте реализован алогоритм ассиметричного шифрования (на самом деле, там сложнее, существуют разные комбинации).
При взаимодействии с терминалом карта выдает криптограмму, которую можно проверить сертификатом ПС, вернее проверить сертификат открытого ключа, который записан на саму же карту эмитентом. Это называется аутентификация карты.
Если бы все так было просто, то в оффлайне бы все левыми картами расплачивались (написав простейший java апплет с левым номером банковской карты). Не надо слишком уж плохо думать о ПС.
А вот далее, после аутентификации идет авторизация. И на транспорте она отложенная — вначале проехал, потом списание. И из-за этого и проблемы. (услугу оказали, а потом выяснилось, что на карте нет денег — кого искать потом перевозчику? эквайрер о держателе тоже ничего не знает) А если делать в онлайне — это долго (для транспорта, особенно в часы «пик»).
Поэтому все известные случаи эмуляции «левых» банковских карт — это либо уязвимости в алгоритмах аутентификации, либо relay атака (танкисты про нее не знают), либо утечка приватных ключей.
PS Еще раз — если терминал никак не аутентифицирует банковскую карту — значит это левый терминал, а не левая карта, сам он и/или его ПО не соответствует требованиям ПС и таких разработчиков надо гнать в шею.
Да, более 15 лет и участие в половине подобных проектов в России. Приведите пример проекта, где риски эквайрер берет на себя. Или только слышали звон?
В подавляющем количестве проектов все риски на перевозчике, либо заложены в комиссию, что, по сути, тоже означает риск на перевозчике.
Допускаю, что в некоторых небольших проектах может быть по-другому. Но там, например, оператор берет с перевозчика в другом месте («за обслуживание»), что только еще раз подтверждает тезис — за все платит перевозчик, и, в конечном итоге, пассажир. Все недостатки притянутых за уши технологий оплачивает потребитель. И так везде. Или для вас это новость? А банкиры они такие альтруисты, на себя риски берут? Не смешно даже.
Я писал выше — виртуальную карту выпустить дело 1 минуты. И катайся. Да, потом обновится стоп-лист, но злоумышленник уже выпустит другую, которой в стоп-листе не будет.
эмуляции «левых» карт не существует. Или поделитесь, как сэмулировать несуществующую, а «выпущенную» хакером псевдобанковскую карту. Есть relay атака или если утекли приватные ключи. Без этого никак.
Вы уверены, что разбираетесь в том, как работают банковские карты? Вы криптограмму как собрались на эмуляторе формировать? Любой pos-терминал имеет сертификаты ПС для проверки криптограммы
Проблема не в «уязвимости токенов» как кто-то тут выразился. Проблема в том, что можно выпускать множество виртуальных карт, не имеющих изначально средств на них. И можно бесплатно ездить. А если карта поставлена в стоп-лист — выпустить новую.
Также есть проблема, что сейчас на карте средств нет, а услуга оказана (пассажир уже проехал). И когда на карте появятся деньги — не известно и не понятно. Это пярмые риски и убытки перевозчиков.
На самом деле, вся беда в том, что пытаются скрестить «ужа с ежом».
Оплата банковскими картами в транспорте подается как нечто инновационное, замена оплаты наличными деньгами, как новый массовый продукт.
А на самом деле, инновационность должна быть в том, чтобы сводить к минимуму сам процесс оплаты в транспорте. пассажир уже должен заходить в транспорт с электронным билетом, который был приобретен заранее по той же самой банковской карте, но в онлайне.
И тогда риски будут сведены к минимуму. А оплта банковской картой в транспорте — это нишевый прордукт, для тех, кто ездит редко — тому нет смысла покупать электронный билет, но разовая поездка должна быть дороже, а риски перекладываются уже на пассажира — хочешь платить здесь и сейчас — плати дороже.
А для часто ездящих пассажиров — долгосрочный билет, проибретенный заранее, за который еще и скидка предоставляется, и по которому рисков неплатежа нет (покупка в онлайне проиводится).
А у нас, как обычно, мнимая цифровизация: взяли и дали кондуктору pos-терминал. раньше платил наличкой, покупая разовые поездки, теперь банковской картой.
Принципиально ничего не поменялось, выгоды для перевозчика нет, зато есть реальные затраты (на эквайринг) и реальные риски неплатежей.
В итоге, как написал выше, за такую мнимую цифровизацию платит пассажир — так как в конечном итоге все риски выливаются в повышение тарифа.
хорошая статья. и комментарии ценные. предварительно можно понять, кто в них засветился: кодеры или разработчики
«основная задача продавщицы - подавать водку и хлеб с полки, больше она покупателю ничего не должна, тем более улыбаться, быть вежливой, предложить еще что-то или про акцию напомнить»
Я в ответ пришлю инфу по аутентификации банковских карт
А кто разработчик системы в Красноярске? К ним появились вопросы.
Судя по вашему профилю, я занимаюсь платежными системами почти столько же, сколько Вам лет.
Поэтому рекомендую изучить, что такое аутентификация карты и что такое авторизация.
Кстати, на хабре много статей писали на эту тему.
А то по вашей логике, я могу взять, в любую Java карту запихнуть в EF pan в нужном формате и по ней проехать? Смешно.
Надеюсь, как изучите вопрос, Вам хватит мужества извиниться.
Всем остальным объясняю: на любой банковской карте реализован алогоритм ассиметричного шифрования (на самом деле, там сложнее, существуют разные комбинации).
При взаимодействии с терминалом карта выдает криптограмму, которую можно проверить сертификатом ПС, вернее проверить сертификат открытого ключа, который записан на саму же карту эмитентом. Это называется аутентификация карты.
Если бы все так было просто, то в оффлайне бы все левыми картами расплачивались (написав простейший java апплет с левым номером банковской карты). Не надо слишком уж плохо думать о ПС.
А вот далее, после аутентификации идет авторизация. И на транспорте она отложенная — вначале проехал, потом списание. И из-за этого и проблемы. (услугу оказали, а потом выяснилось, что на карте нет денег — кого искать потом перевозчику? эквайрер о держателе тоже ничего не знает) А если делать в онлайне — это долго (для транспорта, особенно в часы «пик»).
Поэтому все известные случаи эмуляции «левых» банковских карт — это либо уязвимости в алгоритмах аутентификации, либо relay атака (танкисты про нее не знают), либо утечка приватных ключей.
PS Еще раз — если терминал никак не аутентифицирует банковскую карту — значит это левый терминал, а не левая карта, сам он и/или его ПО не соответствует требованиям ПС и таких разработчиков надо гнать в шею.
В подавляющем количестве проектов все риски на перевозчике, либо заложены в комиссию, что, по сути, тоже означает риск на перевозчике.
Допускаю, что в некоторых небольших проектах может быть по-другому. Но там, например, оператор берет с перевозчика в другом месте («за обслуживание»), что только еще раз подтверждает тезис — за все платит перевозчик, и, в конечном итоге, пассажир. Все недостатки притянутых за уши технологий оплачивает потребитель. И так везде. Или для вас это новость? А банкиры они такие альтруисты, на себя риски берут? Не смешно даже.
Также есть проблема, что сейчас на карте средств нет, а услуга оказана (пассажир уже проехал). И когда на карте появятся деньги — не известно и не понятно. Это пярмые риски и убытки перевозчиков.
На самом деле, вся беда в том, что пытаются скрестить «ужа с ежом».
Оплата банковскими картами в транспорте подается как нечто инновационное, замена оплаты наличными деньгами, как новый массовый продукт.
А на самом деле, инновационность должна быть в том, чтобы сводить к минимуму сам процесс оплаты в транспорте. пассажир уже должен заходить в транспорт с электронным билетом, который был приобретен заранее по той же самой банковской карте, но в онлайне.
И тогда риски будут сведены к минимуму. А оплта банковской картой в транспорте — это нишевый прордукт, для тех, кто ездит редко — тому нет смысла покупать электронный билет, но разовая поездка должна быть дороже, а риски перекладываются уже на пассажира — хочешь платить здесь и сейчас — плати дороже.
А для часто ездящих пассажиров — долгосрочный билет, проибретенный заранее, за который еще и скидка предоставляется, и по которому рисков неплатежа нет (покупка в онлайне проиводится).
А у нас, как обычно, мнимая цифровизация: взяли и дали кондуктору pos-терминал. раньше платил наличкой, покупая разовые поездки, теперь банковской картой.
Принципиально ничего не поменялось, выгоды для перевозчика нет, зато есть реальные затраты (на эквайринг) и реальные риски неплатежей.
В итоге, как написал выше, за такую мнимую цифровизацию платит пассажир — так как в конечном итоге все риски выливаются в повышение тарифа.
Проблемы есть и они серьезные.