Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 116
Все это разбивается о продавщицу, которая не смотрит на документы того, кто платит.
Об продавщицу разбивается только проверка подписи, и то если она требуется. А все остальное — остается в силе.
В Европе у меня везде ID спрашивали, приходилось таскать права с собой. Без ID что-то купить невозможно.
А карта у вас была не европейская? Скорее всего повышенное внимание к international currency / international country транзакциям.
Где в Европе? Я сколько ни катаюсь, паспорт показываю ровно два раза: на въезде и на выезде из Европы. А так даже в самолет просто по посадочному пускают часто, на документы не смотрят. Везде и всё оплачиваю карточкой.
Британия — тотальный EMV.
США — тотальная магнитка.
Автору — коллеге привет!
США — тотальная магнитка.
Автору — коллеге привет!
Аналогично. Только в Мадриде, в медиамаркт, за покупку под 300 евро спросили паспорт. А так паспорт показывал на въезде и выезде из Европы.
У вас пин надо вводить? У меня нет, наверно поэтому нужен ID. ID это не обязательно паспорт, подойдут и российские права. А в Европе, например в Швеции.
У вас просят подписать чек? Если для вашей карты не нужно вводить пин, скорее всего в приоритете CVM стоит проверка подписи. Для этого и требуют ID, на них обычно есть ваша подпись.
Нет, там фамилия и имя написаны и фото есть. Речь не об этом, а о том, что в России можно взять карту чью-то с пином или без и ходить спокойно ей расплачиваться. Спрашивается, какая разница, что там в чипе?
Странно, у меня не получалось дать другому свою карту, чтобы он ею расплачивался. Несмотря на то, что там ни фамилии нет, ни фотографии. Всегда пин просит. Может, есть разница, что там в чипе?
В статье же написали: и чип и терминал имеют приоритезированный список методов аутентификации. Два списка объединяются по «И» и наиболее приоритетный метод используется для проведения транзакции.
Ну, как бы, да. Меня смутила фраза: «в России можно взять карту чью-то с пином или без и ходить спокойно ей расплачиваться». Непонятно, чем Россия от прочих стран отличается и почему с моей картой такие фокусы не проходят.
«Можно» не означает, что будет работать всегда. Принципиальная возможность есть. Я, во всяком случае, прочитал этот комментарий именно так.
Думаю, ничем, просто у автора комментария нет карт жителей других стран и он не может говорить за всех. Вполне здравая позиция.
Вероятно, в вашей карте в приоритете другие методы. Или вы в других местах расплачиваетесь.
Приоритет методов от карточной программы может зависеть. Может, где-то его даже самому менять можно, не знаю. Во всяком случае, технических ограничений на это нет.
Непонятно, чем Россия от прочих стран отличается
Думаю, ничем, просто у автора комментария нет карт жителей других стран и он не может говорить за всех. Вполне здравая позиция.
почему с моей картой такие фокусы не проходят.
Вероятно, в вашей карте в приоритете другие методы. Или вы в других местах расплачиваетесь.
Приоритет методов от карточной программы может зависеть. Может, где-то его даже самому менять можно, не знаю. Во всяком случае, технических ограничений на это нет.
Я этот комментарий прочитал по-другому, если отталкиваться от начала обсуждения. Там человек говорит, что все эти чипы бессмысленны, если продавщица документы не смотрит. Потом говорит, что у него на карте пин вводить не надо. Потом обобщает свой опыт на все российские карты, неважно, с пином или без и спрашивает, какая разница, что там в чипе?
Но разница-то есть, о чём я и попытался сказать в комментарии. Если в чипе стоит в приоритете «всегда спрашивать пин», то он и будет всегда спрашиваться. Особенно в моём случае, когда на карте нет ни фамилии, ни фотографии.
У меня как-то спросили в магазине документы, я в ответ спросил, на какую фамилию? ;-) И показал, что на карточке фамилии нету, с чем сверяться будете? Они посмеялись и сказали, что хозяин потребовал, чтобы продавцы всегда документы спрашивали. Против инструкции не попрёшь.
Но разница-то есть, о чём я и попытался сказать в комментарии. Если в чипе стоит в приоритете «всегда спрашивать пин», то он и будет всегда спрашиваться. Особенно в моём случае, когда на карте нет ни фамилии, ни фотографии.
У меня как-то спросили в магазине документы, я в ответ спросил, на какую фамилию? ;-) И показал, что на карточке фамилии нету, с чем сверяться будете? Они посмеялись и сказали, что хозяин потребовал, чтобы продавцы всегда документы спрашивали. Против инструкции не попрёшь.
Чип позволяет провести аутентификацию карты, то есть проверить ее подлинность, и оценить риски транзакции. Вы говорите о верификации пользователя карты.
Не затруднит раскрыть тему ввода пина\подписи? В моём случае имеется карта аж с 3 возможностями оплаты: полоса, чип и paypass. Иногда, при оплате чипом и успешном вводе кода, продавцы требую расписаться на чеке. Что-то мне подсказывает, что это, во-первых, не безопасно, а во-вторых не понятно, имеют ли они на это право? Кто регулирует процедуру и как она должна выглядить?
В пункте 6. Проверка держателя карты CVM есть небольшое описание. Также вот хорошая статья. Пин имеет больший приоритет над подписью и после его ввода проверять подпись не нужно. У вас все продавцы требуют пин и подпись в разных торговых точках?
Сталкивался несколько раз, закономерности какой-то нет. Все разы были в точках, в которых я первый и, вероятно, последний раз.
Я читал этот пункт, и представляю себе так: если введён и принят пин, то ни о какой подписи речи не идёт. Если терминал по какой-то причине не поддерживает ввод пина, то я его и не должен вводить, расписавшись лишь на чеке после успешной транзакции.
Отсюда опять вопрос — имеют ли право требовать (именно требовать, а не «не могли бы ещё и тут подписать»), и что об этом говорит сам мастеркард, например, или банк-эквайер? При требовании слышал такую версию, что якобы «нам хозин велит» требовать подпись. Должны же быть какие-то общие правила?
Я читал этот пункт, и представляю себе так: если введён и принят пин, то ни о какой подписи речи не идёт. Если терминал по какой-то причине не поддерживает ввод пина, то я его и не должен вводить, расписавшись лишь на чеке после успешной транзакции.
Отсюда опять вопрос — имеют ли право требовать (именно требовать, а не «не могли бы ещё и тут подписать»), и что об этом говорит сам мастеркард, например, или банк-эквайер? При требовании слышал такую версию, что якобы «нам хозин велит» требовать подпись. Должны же быть какие-то общие правила?
Комментарий про ущербность банковской системы и блокчейн.
Как понять что происходит, когда в магазине спрашивают одновременно и подпись и пин-код?
Пин-код спрашивает терминал, подпись — кассир (следуя указаниями терминала или внутреннему порядку работы с терминалом). Возможно кассир не разобрался с терминалом, либо банк эквайер по своим соображениям заложил такую возможность.
Т.е. эквайер может требовать и то и другое? Просто с моей стороны выглядит так: я оставляю подпись, как подтверждение операции, а мне ещё подсовывают какой-то калькулятор с проводом и просят оставить там пин-код. Хотя очевидно, что операция может быть проведена без него.
Я сталкивался с еще более непонятной ситуацией — в РЖД несколько лет назад мою карту провели магнитной лентой И заставили ввести пин-код. Больше с таким нигде не сталкивался.
По спецификации терминал должен требовать что-то одно. Если коробочка вам не нравится — не платите в такой торговой точке, а если заплатили — обратитесь в банк. Особенно если операция проводится/проводилась fallback-ом по магнитной полосе.
Почему бы не идентифицировать владельца банкоматом не пин-кодом, а отпечатком пальца например? Я попал в такую ситуацию — после снятия денег в банкомате вытащили кошелек и сняли все деньги с карты введя мой пин. Видимо где-то была скрытая камера (поскольку рядом со мной никого не было, что бы подсмотреть) или подложная клавиатура.
От копирования карты защитили, а от кражи пина — нет.
От копирования карты защитили, а от кражи пина — нет.
А что бы вы предпочли: потерять деньги или палец/глаз?
(отпечатки пальцев до сих пор не вводят, т.к. есть риск отделения последних от владельца)
(отпечатки пальцев до сих пор не вводят, т.к. есть риск отделения последних от владельца)
Разработки идут в этом направлении. MasterCard экспериментирует с распознаванием образов и со сканером отпечатков пальцев.
Я не сказала, что технологии нет.
Имелось ввиду, что вводить в эксплуатацию — опасно.
Более того, отпечаток пальцев не удобен. Те же проблемы что и с телефоном зимой — перчатки приходится снимать.
К тому же есть ряд профессий, как бармены, их кожа постоянно поддаётся воздействию разных кислот (попробуйте за 8 часов сделать 100 махито), итд. Но это вы и без меня знаете :)
Имелось ввиду, что вводить в эксплуатацию — опасно.
Более того, отпечаток пальцев не удобен. Те же проблемы что и с телефоном зимой — перчатки приходится снимать.
К тому же есть ряд профессий, как бармены, их кожа постоянно поддаётся воздействию разных кислот (попробуйте за 8 часов сделать 100 махито), итд. Но это вы и без меня знаете :)
А как вы думаете, что потенциально более безопасно: код, который знаете только вы, или отпечаток, который вы оставляете везде?
Промахнулся, это я Semy
Промахнулся, это я Semy
Отличная статья!
Я вот только хотел спросить:
Представим ситуацию, когда я через интернет-банк поменял PIN-код на своей EMV-карте. Дальше я иду в банкомат или магазин, где принимают карты. Я ввожу там свой новый пин-код. Вопрос: в этой ситуации пин-код отправляется в банк или же делаются некие математические (криптографические) операции, чтобы не передавать непосредственно пин? Ну и побочный вопрос: офлайн пин устанавливается на основе того нового пина, что я ввел, или же присылается из банка?
Прошу прощения, если это освещено в статье. Возможно, эта информация от меня ускользнула или я что-то недопонял.
Я вот только хотел спросить:
Представим ситуацию, когда я через интернет-банк поменял PIN-код на своей EMV-карте. Дальше я иду в банкомат или магазин, где принимают карты. Я ввожу там свой новый пин-код. Вопрос: в этой ситуации пин-код отправляется в банк или же делаются некие математические (криптографические) операции, чтобы не передавать непосредственно пин? Ну и побочный вопрос: офлайн пин устанавливается на основе того нового пина, что я ввел, или же присылается из банка?
Прошу прощения, если это освещено в статье. Возможно, эта информация от меня ускользнула или я что-то недопонял.
Пойдет ли ваш пин-код, введенный с банкомата в банк, зависит от настройки банкомата и карты. Если требуется использовать Онлайн-PIN, то он отправится в банк и там уже конечно будут сравнивать его с новым установленным. Далее от банка придет Issuer Script, который вам поменяет пин на самой карте.
Вот тут много информации про пин. Тут больше вопрос к поведению банкомата. Так как банкоматы всегда онлайн, скорее всего банкомат сначала сменит онлайн пин в системе, после чего банк-эмитент пришлет скриптовые команды нового оффлайн пина для карты, и банкомат сразу сменит офлайн пин на карточке. Хотя я точно не уверен.
В общем правильно, чуть формулировка не точна :)
Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Вот только жаль, что эту операцию не стандартизировали и смена PIN в общем случае доступна только в «своей» инфраструктуре.
Нет стандарта (в разных реализациях ПО процессинга) на данный тип «транзакции» и способ передачи нового PIN (PIN блок с новым PIN). У каждой реализации свои особенности и… межхост с большой долей вероятности запрос смены PIN не пройдет.
Ну и для подобных служебных операций в EMV зарезервирован фактически (ну по крайней мере его так используют) режим, когда терминал карте на первый GenerateAC говорит AAC и идет в on-line что бы получить скрипт.
Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Вот только жаль, что эту операцию не стандартизировали и смена PIN в общем случае доступна только в «своей» инфраструктуре.
Нет стандарта (в разных реализациях ПО процессинга) на данный тип «транзакции» и способ передачи нового PIN (PIN блок с новым PIN). У каждой реализации свои особенности и… межхост с большой долей вероятности запрос смены PIN не пройдет.
Ну и для подобных служебных операций в EMV зарезервирован фактически (ну по крайней мере его так используют) режим, когда терминал карте на первый GenerateAC говорит AAC и идет в on-line что бы получить скрипт.
Спасибо за уточнение, конечно же пин будет менять хост авторизации.
Если первый Generate AC вернет AAC терминал может завершить транзакцию без выхода в online и получения скриптов.
Вероятно, имелся в виду запрос ARQC в первом Generate AC, выход онлайн с проверкой ARQC и получением ARPC и скриптов.
Вероятно, имелся в виду запрос ARQC в первом Generate AC, выход онлайн с проверкой ARQC и получением ARPC и скриптов.
Нет именно AAC карте(!) передает терминал в первой GenerateAC. Понятно что карта возвращает то же AAC и криптограмму. И с этой криптограммой терминал идет на авторизацию.
Авторизацию опять же служебной операции специально «раскрашенную» как служебный запрос.
Хочу обратить внимание, что по EMV не специфицированно ограничений и скрип выполняется вне зависимости от того AAC, или ARQC терминал выдал после первой GenerateAC.
Используется для служебных функций (не платежных!) в служебном терминале и/или ATM.
Например — запрос баланса.
Некоторые вендоры ПО, запрос баланса по EMV карте делают через обычный ARQC с '00..0' полями сумм, а некоторые через AAC. Видел и тот и другой вариант. И то и другое работает (нет стандарта на служебные операции).
Лично мне кажется, из очень общих соображений, что через AAC правильнее. Ну что бы точно было видно «ЭТО НЕ платежная транзакция»
Аналогично и смена PIN то же служебная операция.
Конечно смену PIN можно запрашивать и совместно с платежом, но концептуально не правильно мешать…
Авторизацию опять же служебной операции специально «раскрашенную» как служебный запрос.
Хочу обратить внимание, что по EMV не специфицированно ограничений и скрип выполняется вне зависимости от того AAC, или ARQC терминал выдал после первой GenerateAC.
Используется для служебных функций (не платежных!) в служебном терминале и/или ATM.
Например — запрос баланса.
Некоторые вендоры ПО, запрос баланса по EMV карте делают через обычный ARQC с '00..0' полями сумм, а некоторые через AAC. Видел и тот и другой вариант. И то и другое работает (нет стандарта на служебные операции).
Лично мне кажется, из очень общих соображений, что через AAC правильнее. Ну что бы точно было видно «ЭТО НЕ платежная транзакция»
Аналогично и смена PIN то же служебная операция.
Конечно смену PIN можно запрашивать и совместно с платежом, но концептуально не правильно мешать…
Все верно, для любой скриптовой команды изменяющей данные приложения потребуется состояние ONLINE или SCRIPT (выход в онлайн с любым результатом). Через AAC в первом GenerateAC просто получается быстрее.
Нет смысла выполнять второй GenerateAC, потому что не нужно оценивать риски (это не платежная операция, как было сказано выше) и не нужно аутентифицировать картой банк через ARPC (потому что данные придут, как минимум макированые на ключе эмитента).
Нет смысла выполнять второй GenerateAC, потому что не нужно оценивать риски (это не платежная операция, как было сказано выше) и не нужно аутентифицировать картой банк через ARPC (потому что данные придут, как минимум макированые на ключе эмитента).
Т.е. в чужом банкомате я смогу снять по новому пину, а если потом попробовать ввести новый пин в офлайн-терминале, то могу обломаться?
после первого же снятия по онлайн-пину (если это операция по чипу) на карту придёт issuer script, который обновит данные, в том числе и оффлайн-пин.
>Хост авторизации сменит on-line PIN и отправит скрипт с установкой нового PIN.
Конечно, поскольку операция установки нового on-line PIN на хосте и замена PIN приложения карты, командой скрипта с хоста не транзакционна, то есть вероятность того, что on-line PIN сменился, а off-line нет.
(термин «транзакционна» в данном случае — это термин… ну как в СУБД. т.е. завершена полностью или откачена операция).
За все реализации и вендоров ПО хоста говорить не буду, но варианты компенсации этой ситуации прозрачно для клиента можете сами прикинуть.
Кто то просто игнорирует с сакраментальным «обращайтесь в офис банка».
Конечно, поскольку операция установки нового on-line PIN на хосте и замена PIN приложения карты, командой скрипта с хоста не транзакционна, то есть вероятность того, что on-line PIN сменился, а off-line нет.
(термин «транзакционна» в данном случае — это термин… ну как в СУБД. т.е. завершена полностью или откачена операция).
За все реализации и вендоров ПО хоста говорить не буду, но варианты компенсации этой ситуации прозрачно для клиента можете сами прикинуть.
Кто то просто игнорирует с сакраментальным «обращайтесь в офис банка».
Я про этот кусок:
смена PIN в общем случае доступна только в «своей» инфраструктурет.е. если я буду снимать деньги в чужом банкомате, то существует вероятность что мне не придёт новый пин.
Функция (кнопка/пункт меню в интерфейсе банкомата) смены PIN доступна обычно только для «своего» банкомата (банкомат знает про эмитента карты и знает что ему разрешена эта операция).
Если Вы говорите про установку PIN через IVR (телефон) или интернет банк… то новый off-line PIN придет в рамках первой же успешной on-line авторизации по чипу в ЛЮБОМ терминале любого типа.
Ну должен по крайней мере. (были прецеденты, когда промежуточные хосты «резали» скрипт эмитента)
Если Вы говорите про установку PIN через IVR (телефон) или интернет банк… то новый off-line PIN придет в рамках первой же успешной on-line авторизации по чипу в ЛЮБОМ терминале любого типа.
Ну должен по крайней мере. (были прецеденты, когда промежуточные хосты «резали» скрипт эмитента)
Я отказываюсь считать такую схему безопасной. До тех пор, пока кто-то может списать деньги с моего счёта без моего ясного «да, я разрешаю списать 100 денег пупкину А А» — это не безопасность, а филькина грамота.
Paypal уделывает по этому вопросу все банковские сервисы вместе взятые. Целиком. Просто потому, что требует нажать «да, заплатить» со стороны пользователя.
Paypal уделывает по этому вопросу все банковские сервисы вместе взятые. Целиком. Просто потому, что требует нажать «да, заплатить» со стороны пользователя.
Этого парня все устраивает в безопасности вашей карточки
Этот парень, похоже, просто вез терминал в руках и неожиданно стал «звездой» интернета. Можно еще с натяжкой поверить что он считывал mifare проездные платежным терминалом. Далеко не все бесконтактные карты можно просто так считать, и даже если считали — делать с этими данными практически нечего. По поводу проведения таким способом транзакций приведу цитату из указанного вами источника:
«Сделать терминал, который будет считывать данные карты «из кармана» клиента, теоретически возможно. Но этот терминал должен иметь «на борту» криптографические ключи, полученные у банка-эквайера и платежной системы. Ключи выдаются по договору с юридическим лицом, то есть с банком-эквайером. Таким образом, мошенничество будет легко обнаружить и расследовать»
«Сделать терминал, который будет считывать данные карты «из кармана» клиента, теоретически возможно. Но этот терминал должен иметь «на борту» криптографические ключи, полученные у банка-эквайера и платежной системы. Ключи выдаются по договору с юридическим лицом, то есть с банком-эквайером. Таким образом, мошенничество будет легко обнаружить и расследовать»
Расследовать все легко, если вы следователь. Я сам сталкивался со случаями, когда расследование было завершено на стадии подачи заявления, а ход делу не давали. Взять любые мошеннические действия с утекающими через онлайн банкинги через вирусы/малвари/скрипты или «ваша карта заблокирована». Как правило всегда ответ от банка «это с вашего компьютера/мобильника/планшета действия а как эквивалент ваша воля, мы не видим тут противоправных действий и деньги не вернем». Хотя контрагенты это реальные физически/юридические лица, а не биткоин кошельки. Так же и тут, вы просто не заметите пропажи 500р.
Со скомпрометированным юрлицом будет другой разговор. Хватит нескольких запросов ведущих в одну и ту же платежную точку.
Да и прав mmMike — как то это мелко при большой сложности. Оформить юрлицо, пройти 10 кругов ада получения терминала, долго искать карты у которых есть лимиты на операции без пина, что-бы потом красть по 1000 рублей. Затраты не отобьются.
СМС оповещения помогают заметить все списания по счету.
Да и прав mmMike — как то это мелко при большой сложности. Оформить юрлицо, пройти 10 кругов ада получения терминала, долго искать карты у которых есть лимиты на операции без пина, что-бы потом красть по 1000 рублей. Затраты не отобьются.
СМС оповещения помогают заметить все списания по счету.
В принципе можно организовать в режиме on-line платеж путем создания канала между картой в кармане жертвы и сотовым телефоном, эмулирующим работу бесконтактной карты (HCE приложение).
Всего то нужно два телефона с NFC, хост с белым IP для проброса трафика в on-line между двумя телефонами и очень четкая синхронизация двух злоумышленников.
И… они могут получить бесплатный завтрак в макдональс! (а на большее без ПИН лимита не хватит) или от 5 лет… Если кассир заподозрит неладное.
Но как то это фриково… Мелочь по карманам в том же общественном транспорте тырить — навар больше будет.
А уж просто стырить карту и расплатится ей в пределах без PIN лимита — еще безопаснее.
Не верю я в таких квалифицированных в области программизма мелких карманников.
Всего то нужно два телефона с NFC, хост с белым IP для проброса трафика в on-line между двумя телефонами и очень четкая синхронизация двух злоумышленников.
И… они могут получить бесплатный завтрак в макдональс! (а на большее без ПИН лимита не хватит) или от 5 лет… Если кассир заподозрит неладное.
Но как то это фриково… Мелочь по карманам в том же общественном транспорте тырить — навар больше будет.
А уж просто стырить карту и расплатится ей в пределах без PIN лимита — еще безопаснее.
Не верю я в таких квалифицированных в области программизма мелких карманников.
Спасибо за статью.
Хотелось бы еще статей на тему банкинга и проведения транзакций.
Хотелось бы еще статей на тему банкинга и проведения транзакций.
Мне еще вот эта статья понравилась про способы проверки пин-кода. Там в частности написано, что «зашифрованный офлайн-ПИН – самый современный и защищенный способ верификации».
Стоит уточнить что «защищенный способ верификации держателя карты», но не аутентификации карты. По большому счету, офлайн-пин больше предназначен для офлайн-транзакций, чем общий способ верификации. В итоге не корректно говорить о том, что какой-то из способов проверки пинов более защищенный и современный. У них разные задачи.
офлайн-пин больше предназначен для офлайн-транзакций
Очень много инфраструктур POS, где POS терминалы вообще без on-line PIN (Франция… Германия...)
И используется off-line PIN с on-line авторизацией.
Особенно там, где традиционно работали с чиповыми картами (местные не EMV платежные системы а чиповых картах).
Накладные расходы на загрузку TMK/TPK ключей в криптомодуль клавиатуры — это не мало…
Накладные расходы на загрузку TMK/TPK ключей в криптомодуль клавиатуры — это не мало…
Ну вообще говоря, мастер-ключи в клавиатуры банкоматов (про ПОСы не скажу) можно загрузить при помощи ассимметричной криптографии, и уже довольно давно (если не ошибаюсь, то больше 5 лет). Так что особых накладных расходов быть не должно.
Я говорил про POS терминалы.
В масштабах большей инфраструктуры, 2-20 Euro на загрузку POS терминала — это не мало
(по разным оценкам и по разным технологиями и разных странах… в сумму входят и зарплаты сотрудникам… чел./часы и пр.)
А накладные расходы на загрузку ключей в криптомодуль клавиатуры банкомата это малая часть расходов по установке и настройке банкоматов.
Разница, на общем фоне затрат на установку железки, между классической загрузкой компонент симметричных ключей с бумажек и более продвинутыми вариантами не столь принципиальна по стоимости.
Да и банкомат по определению (требования ПС) с on-line PIN. вариантов нет.
Ну и сети банкоматов обычно на порядок меньше чем POS (в общем случае)
В масштабах большей инфраструктуры, 2-20 Euro на загрузку POS терминала — это не мало
(по разным оценкам и по разным технологиями и разных странах… в сумму входят и зарплаты сотрудникам… чел./часы и пр.)
А накладные расходы на загрузку ключей в криптомодуль клавиатуры банкомата это малая часть расходов по установке и настройке банкоматов.
Разница, на общем фоне затрат на установку железки, между классической загрузкой компонент симметричных ключей с бумажек и более продвинутыми вариантами не столь принципиальна по стоимости.
Да и банкомат по определению (требования ПС) с on-line PIN. вариантов нет.
Ну и сети банкоматов обычно на порядок меньше чем POS (в общем случае)
>> офлайн-пин больше предназначен для офлайн-транзакций
оффлайн-пин прекрасно подходит и используется для онлайн транзакций, так как проводит верификацию пина моментально, ускоряя тем самым общее время проведения транзакции в целом.
оффлайн-пин прекрасно подходит и используется для онлайн транзакций, так как проводит верификацию пина моментально, ускоряя тем самым общее время проведения транзакции в целом.
не по этой причине все же…
экономия 10-100ms на проверку PIN блока в HSM, это не основополагающая причина.
экономия 10-100ms на проверку PIN блока в HSM, это не основополагающая причина.
отправка и ожидание онлайн верификации пина на хосте вместо мгновенной проверки в чипе — это как раз одна из весомых причин.
Мы же об одном говорим и подразумеваем?
А именно авторизацю транзакции на хосте эмитента.
Или вы имеете в вижу что то другое. Я не понял
В контексте авторизационного запроса эмитенту.
Поясните пожалуйста
А именно авторизацю транзакции на хосте эмитента.
Или вы имеете в вижу что то другое. Я не понял
отправка и ожидание онлайн верификации пина на хосте вместо мгновенной проверки в чипе
В контексте авторизационного запроса эмитенту.
Поясните пожалуйста
Нет, мы говорим об онлайн и оффлайн проверке PIN-кода.
При проведении оффлайн проверки, общая скорость обслуживания клиента возрастает, так как оффлайн проверка проходит гораздо быстрее нежели онлайн.
При проведении оффлайн проверки, общая скорость обслуживания клиента возрастает, так как оффлайн проверка проходит гораздо быстрее нежели онлайн.
Мне было бы очень интересно услышать Ваше представление об порядке выполнении платежной транзакции в режиме on-line в POS терминале для EMV карты, включая запросы к хосту и действия хоста на запросы.
Порядок выполнения по шагам + оценка времени каждого шага.
В двух вариантах: c off-line PIN и on-line PIN.
Ну очень интересно, где по вашему мнению возникает «гораздо быстрее нежели онлайн».
Если уж высказали так уверено свое мнение, то его нужно обосновывать…
Порядок выполнения по шагам + оценка времени каждого шага.
В двух вариантах: c off-line PIN и on-line PIN.
Ну очень интересно, где по вашему мнению возникает «гораздо быстрее нежели онлайн».
Если уж высказали так уверено свое мнение, то его нужно обосновывать…
Еще раз уточню. Не в общем абстрактном случае, а именно в случае on-line авторизации
При выполнении авторизации транзакции на хосте эмитента, не важно с точки зрения скорости обслуживания клиента, какой вариант проверки PIN используется.
При выполнении авторизации транзакции на хосте эмитента, не важно с точки зрения скорости обслуживания клиента, какой вариант проверки PIN используется.
На самом деле вся эта система работает ровно до тех пор пока банковское ПО работает в соответствии с гайдлайнами и стандартами платежных систем, а органы отвечающие за сертификацию этого дела — знают что они делают и делают это ответственно.
Волею судеб оказался вовлеченным в процесс платежей, причем не в России, а внезапно в Нигерии (да-да, шутка про нигерийские письма), так что немного расскажу про свой опыт и творящийся там бедлам. Очень хочется услышать комментарии тех, кто занимается этим в РФ, надеюсь у нас все гораздо лучше с безопасностью.
История 1. Захотели они сделать POS-терминалы из смартфона. Окей, закупаются кардридеры (сертифицированные EMV, стоят они дешево, в итоге смарт + ридер выходит дешевле классического POS-терминала), они подключаются к смартфону (по блютусу или через аудиоразъем), пишется софт, все хорошо. Но тут же всплывают нюансы. Например чтобы сделать подешевле — закупаются ридеры без pin-pad. По задумке создателей они могут использоваться только с верификацией подписью на экране смартфона. Я такое даже в РФ один раз в такси использовал. Но есть нюанс — в Нигерии все банки признают только PIN авторизацию. Что же делать? Ну ясен пень, вводим пин просто на экране смартфона. Пофиг что это запрещено правилами EMV (нигерийцам правда тоже на них слегка пофиг, у них распространена своя платежная система Verve), пофиг что никакой секьюрности пина в таком случае нет.
В итоге все работает, да. Карта думает что транзакция подтверждена подписью (ей ридер сообщает это в списке поддерживаемых CVM), нигерийский процессинговый центр думает что подтверждено пином.
То есть обмануть карту вполне можно. При этом софт получил сертификацию их центрального банка.
История 2. Запросы в ПЦ шлются по незашифрованному каналу. Эти умники до сих пор не осилили запустить свой iso8583 — канал поверх SSL. И это вообще пц, так как получается что открытым текстом шлются почти все платежные данные. Кроме PIN — он шифруется отдельным ключом. В общем взломав вайфай в магазине и просмотрев траффик с терминала можно получить достаточно данных для совершения платежей.
Причем NIBSS — это прям серьезная центральная государственная организация, которая пользуясь неограниченным административным ресурсом за несколько лет до этого выдавила с рынка обработки платежей всех конкурентов, а теперь вот такое учиняет. Что-то мне это напоминает…
История 3.
Как раз насчет processing code. Нормально он подделывается =) Во всяком случае опять же если те, кто отвечает за софт на стороне банка, кладут на него болт. В какой-то момент приходилось составлять данные для платежа вручную, имея лишь часть необходимой информации. Так как ридер выдавал большую часть данных в зашифрованном виде, но ПЦ не поддерживал этот вид шифрования, а расшифровать перед отправкой их было нельзя (для этого нужен ключ девайса, который производитель не дает кому попало, а только важным банкам и организациям, но не разработчикам). В общем почти все нужные данные и так получилось выдрать, но вот как раз этот код был в итоге захардкожен и все работало нормально.
Короче не храните деньги в нигерийских банках, хехе.
Волею судеб оказался вовлеченным в процесс платежей, причем не в России, а внезапно в Нигерии (да-да, шутка про нигерийские письма), так что немного расскажу про свой опыт и творящийся там бедлам. Очень хочется услышать комментарии тех, кто занимается этим в РФ, надеюсь у нас все гораздо лучше с безопасностью.
История 1. Захотели они сделать POS-терминалы из смартфона. Окей, закупаются кардридеры (сертифицированные EMV, стоят они дешево, в итоге смарт + ридер выходит дешевле классического POS-терминала), они подключаются к смартфону (по блютусу или через аудиоразъем), пишется софт, все хорошо. Но тут же всплывают нюансы. Например чтобы сделать подешевле — закупаются ридеры без pin-pad. По задумке создателей они могут использоваться только с верификацией подписью на экране смартфона. Я такое даже в РФ один раз в такси использовал. Но есть нюанс — в Нигерии все банки признают только PIN авторизацию. Что же делать? Ну ясен пень, вводим пин просто на экране смартфона. Пофиг что это запрещено правилами EMV (нигерийцам правда тоже на них слегка пофиг, у них распространена своя платежная система Verve), пофиг что никакой секьюрности пина в таком случае нет.
В итоге все работает, да. Карта думает что транзакция подтверждена подписью (ей ридер сообщает это в списке поддерживаемых CVM), нигерийский процессинговый центр думает что подтверждено пином.
То есть обмануть карту вполне можно. При этом софт получил сертификацию их центрального банка.
История 2. Запросы в ПЦ шлются по незашифрованному каналу. Эти умники до сих пор не осилили запустить свой iso8583 — канал поверх SSL. И это вообще пц, так как получается что открытым текстом шлются почти все платежные данные. Кроме PIN — он шифруется отдельным ключом. В общем взломав вайфай в магазине и просмотрев траффик с терминала можно получить достаточно данных для совершения платежей.
Причем NIBSS — это прям серьезная центральная государственная организация, которая пользуясь неограниченным административным ресурсом за несколько лет до этого выдавила с рынка обработки платежей всех конкурентов, а теперь вот такое учиняет. Что-то мне это напоминает…
История 3.
Как раз насчет processing code. Нормально он подделывается =) Во всяком случае опять же если те, кто отвечает за софт на стороне банка, кладут на него болт. В какой-то момент приходилось составлять данные для платежа вручную, имея лишь часть необходимой информации. Так как ридер выдавал большую часть данных в зашифрованном виде, но ПЦ не поддерживал этот вид шифрования, а расшифровать перед отправкой их было нельзя (для этого нужен ключ девайса, который производитель не дает кому попало, а только важным банкам и организациям, но не разработчикам). В общем почти все нужные данные и так получилось выдрать, но вот как раз этот код был в итоге захардкожен и все работало нормально.
Короче не храните деньги в нигерийских банках, хехе.
Самое забавное, применительно к картам, что даже в 2015 году оставались банки, которые выдавали SDA-only карты (их можно частично склонировать).
Скорей всего это банки, которые закупили когда-то добротную партию SDA-карт и теперь пытаются раздать ее клиентам под любым предлогом. Такое к сожалению встречается повсеместно.
И что такого? Зачем дебетовым карточным продуктам возможность обслуживаться в On-line?
Если это даже правилами запрещено для таких продуктов.
Рекомендованные профили, в которых нет DDA есть у всех платежных систем.
Если это даже правилами запрещено для таких продуктов.
Рекомендованные профили, в которых нет DDA есть у всех платежных систем.
>Зачем дебетовым карточным продуктам возможность обслуживаться в On-line?
Зачем дебетовым карточным продуктам возможность обслуживаться в off-line?
опечатка…
Ну и вдогонку. на чисто On-line картах зачастую даже SDA не делают. Вполне нормальный вариант.
Зачем дебетовым карточным продуктам возможность обслуживаться в off-line?
опечатка…
Ну и вдогонку. на чисто On-line картах зачастую даже SDA не делают. Вполне нормальный вариант.
Вполне обычная Visa Standard. Персонализирована с возможностью off-line операций. Как не сложно догадаться, клонируется на ура.
Visa Standart c SDA и не нулевыми off-line лимитами???!!!
Технически, создать такой профиль персонализации конечно можно.
Но… как то не верю в таких идиотов в банках. Не пуганных идиотов…
Названием банка не поделитесь? страна должна знать своих героев.
Технически, создать такой профиль персонализации конечно можно.
Но… как то не верю в таких идиотов в банках. Не пуганных идиотов…
Названием банка не поделитесь? страна должна знать своих героев.
Сбер. Лимиты X и Y в CVM нулевые. Остальные оффлайновые лимиты для offline-only клона не принципиальны, если я правильно понимаю.
Т.е. Вы хотите сказать, что у Сбера выдаются карты без DDA(CDA) и off-line PIN в CVM??!!! Да еще с нулевыми XY
Если это так, то у меня нет слов! Такие «дыры» в безопасности дискредитирую саму технологию. Хотя она не причем.
Явно у Сбера сознательный выбор, подставляющий невинных клиентов.
Если кто такую карту втихушку продублирует — это даже не магнитку скопировать. Это хуже!
Операции без PIN по магнитке хотя бы весьма ограничены без знания PIN. А тут клон, который «выглядит» гораздо защищенней чем магнитка, а по сути…
И что бы выпустить клон достаточно сосем не много
Любого низкуровнего лога (DGI данных персонализации, лога транзакции на уровне APDU или уже разобранных данных и т.д.) или 2 сек доступа к карте (засунуть в ридер)
Вы точно уверенны, что такие карты есть?
Постараюсь найти такую карту по знакомым с картами Сбер, что бы иметь доказательство…
Все же ссылаться на «слышал» для таких серьезных обвинений это мало.
Поскольку к Сберу отношения не имею, то смотрел (ради любопытства когда то) только свою личную Сберовскую карту. Был и есть честный MChip select c CDA…
Если это так, то у меня нет слов! Такие «дыры» в безопасности дискредитирую саму технологию. Хотя она не причем.
Явно у Сбера сознательный выбор, подставляющий невинных клиентов.
Если кто такую карту втихушку продублирует — это даже не магнитку скопировать. Это хуже!
Операции без PIN по магнитке хотя бы весьма ограничены без знания PIN. А тут клон, который «выглядит» гораздо защищенней чем магнитка, а по сути…
И что бы выпустить клон достаточно сосем не много
Любого низкуровнего лога (DGI данных персонализации, лога транзакции на уровне APDU или уже разобранных данных и т.д.) или 2 сек доступа к карте (засунуть в ридер)
Вы точно уверенны, что такие карты есть?
Постараюсь найти такую карту по знакомым с картами Сбер, что бы иметь доказательство…
Все же ссылаться на «слышал» для таких серьезных обвинений это мало.
Поскольку к Сберу отношения не имею, то смотрел (ради любопытства когда то) только свою личную Сберовскую карту. Был и есть честный MChip select c CDA…
Off-line PIN в CVM не важен. клон спокойно вернет 90 00 на любой пин.
Завтра скину обезличенный дамп. Может быть, я чего-то не понимаю. Я тоже очень удивился, когда Сбер мне такую карточку выдал. Такое впечатление, что они почти не меняли шаблон с 2003 года, когда мне предыдущую Visa Standard выдавали.
Завтра скину обезличенный дамп. Может быть, я чего-то не понимаю. Я тоже очень удивился, когда Сбер мне такую карточку выдал. Такое впечатление, что они почти не меняли шаблон с 2003 года, когда мне предыдущую Visa Standard выдавали.
CVM входит в подпись. Хотя бы и SDA…
Т.е. если в исходной карте не предусмотрен off-line PIN в CVM, то и в дубле его не будет.
Ну и терминал его никогда у карты не спросит. и остается только on-line PIN.
даже подпись клиента на чеке в CVM не так плохо как off-line PIN в CVM на клоне карты.
А вот если есть…
Терминал с off-line транзакцией и без PIN — ну это… например оплата туалета жд. вокзале (в Осло кажется с таким курьезом столкнулся) или… платная дорога.
А вот off-line операцию с off-line PIN вполне могу себе представить как разрешенную в каком ни будь супермаркете на сумму до 50Euro.
И мне было бы обидно кормит на 50Euro «несчастного беженца» которому местная диспора продала клон моей карты, сделанный по украденным в банке данным.
И это не магнитка… с EMV транзакцией замучишься доказывать что «не я там был».
Т.е. если в исходной карте не предусмотрен off-line PIN в CVM, то и в дубле его не будет.
Ну и терминал его никогда у карты не спросит. и остается только on-line PIN.
даже подпись клиента на чеке в CVM не так плохо как off-line PIN в CVM на клоне карты.
А вот если есть…
Терминал с off-line транзакцией и без PIN — ну это… например оплата туалета жд. вокзале (в Осло кажется с таким курьезом столкнулся) или… платная дорога.
А вот off-line операцию с off-line PIN вполне могу себе представить как разрешенную в каком ни будь супермаркете на сумму до 50Euro.
И мне было бы обидно кормит на 50Euro «несчастного беженца» которому местная диспора продала клон моей карты, сделанный по украденным в банке данным.
И это не магнитка… с EMV транзакцией замучишься доказывать что «не я там был».
Доказывается-то на ура (в идеале): криптограмма TC не сойдется. По идее, эквайер может сам послать chargeback, после проверки криптограмм в presentment.
эквайрер… chargeback? после проверки криптограммы? (крипторамму может только эмитент проверить)
И не совсем понял… зачем это эквайреру. Товар отдан. Транзакция по EMV карте по всем правилам ПС. Ничего у эквайрера не нарушено.
Не магнитка. никаких «смещений отвественности». Эмитент обязан ему возместить…
А дальше: TC транзакции проверяет (а чаще всего никто не проверяет) эмитент. И он что? «автоматически» компенсирует потери клиенту? слабо верится.
Все проблемы по подаче заявления и т.п. ложатся на клиента. Это я имею в виду «замучаешься».
Именно «замучаешься», а не «невозможно»
В сущности вопрос, лично у меня остается открытым, как такие диспуты решаются в ПС. По идее, это же эмитент выпустил карту с таким профилем и дырой в безопасности.
И не совсем понял… зачем это эквайреру. Товар отдан. Транзакция по EMV карте по всем правилам ПС. Ничего у эквайрера не нарушено.
Не магнитка. никаких «смещений отвественности». Эмитент обязан ему возместить…
А дальше: TC транзакции проверяет (а чаще всего никто не проверяет) эмитент. И он что? «автоматически» компенсирует потери клиенту? слабо верится.
Все проблемы по подаче заявления и т.п. ложатся на клиента. Это я имею в виду «замучаешься».
Именно «замучаешься», а не «невозможно»
В сущности вопрос, лично у меня остается открытым, как такие диспуты решаются в ПС. По идее, это же эмитент выпустил карту с таким профилем и дырой в безопасности.
Да, эмитент, конечно.
После проверки поддельной криптограммы эмитентом карта сразу должна улететь в стоп-листы. Ответственность по SDA, вроде как, делят эмитент и эквайер. Один такую карту выпустил, второй провел офлайн операцию по такой карте.
После проверки поддельной криптограммы эмитентом карта сразу должна улететь в стоп-листы.
Хм… по секрету скажу (не тыкая пальцем в конкретных...), что TC off-line транзакции обычно мало кто проверяет.
второй провел офлайн операцию по такой карте.
Не так все просто.
Карта с SDA… или карта DDA/CDA
В TVR нет ни одного бита позволяющего различить эти два варианта.
Terminal Action Code — по это все что обычно конфигурируется (можно сконфигурировать) в стандартном EMV терминале (*).
(*) — остальные параметры: Лимиты, публичные ключи и пр. к этой теме отношения не имеют.
И только этим эквайрер может повлиять на принятие решение терминалом.
Все остальное — не стандарт и частные/опциональные кастомизации ПО терминала.
Все же в EMV все очень четко прописано.
Так что эквайрер тогда становится (равная ответственность) невинной жертвой, действующей по правилам!
А насчет равной ответственности… Ссылку на правила Visa/MC, если можно.
И если знаете вендора ПО EMV терминала, где можно указать что SDA только on-line, то пожалуйста поделитесь.
Got tag 8e len 10 'Cardholder Verification Method (CVM) List':
X: 0
Y: 0
41 03: 'Plaintext PIN verification performed by ICC' 'If terminal supports the CVM' and 'continue' if this CVM is unsuccessful
42 03: 'Enciphered PIN verified online' 'If terminal supports the CVM' and 'continue' if this CVM is unsuccessful
5e 03: 'Signature (paper)' 'If terminal supports the CVM' and 'continue' if this CVM is unsuccessful
1f 00: 'No CVM required' 'Always' and 'fail' if this CVM is unsuccessful
00: 00 00 00 00 00 00 00 00 41 03 42 03 5e 03 1f 00 |........A.B.^...
Да… отсутствие «Enciphered PIN verification performed by ICC» практически кричит о том что это карта без RSA
Спасибо! буду знать точно теперь. Сбербанк конечно не пинает только ленивый, но это уже перебор у них.
вот такой CVM, как мне кажется только и может быть допустим для карты без DDA/CDA.
00000000 00000000 0203 1F00
Чисто on-line приложения как прямая замена мегнитки.
Спасибо! буду знать точно теперь. Сбербанк конечно не пинает только ленивый, но это уже перебор у них.
вот такой CVM, как мне кажется только и может быть допустим для карты без DDA/CDA.
00000000 00000000 0203 1F00
Чисто on-line приложения как прямая замена мегнитки.
Да.
При этом, например, тот же сбер выпускает Maestro Momentum как DDA карты.
При этом, например, тот же сбер выпускает Maestro Momentum как DDA карты.
Я бы только ставил… 4203 1f00.
В данном случае, разницы практически никакой (всего одно «действующее» правило связанное с фактической cardholder аутентификацией).
и если CVM по правилу "_203" будет failed, то бит 40 влияет только на то какой будет CVM бит в TVR,
и какая разница, если все одно транзакция по этой карте без on-line PIN запрещена?
может быть даже лучше, если терминал сразу откажет (по маске в TVR) чем пойдет на хост за отказом.
Впрочем, если хочется фиксировать все попытки провести операцию… то почему бы и нет.
в общем не однозначно. и то и то имеет право на жизнь.
главное для всех комбинаций в CVM тщательно расписать все сценарии и настойки хоста, что бы случайно не осталось «дырок» и нежелательных вариантов.
Хотя для такой карты сценарий хоста по CVM прост: нет успешной проверки PIN блока — нет транзакции.
и если CVM по правилу "_203" будет failed, то бит 40 влияет только на то какой будет CVM бит в TVR,
и какая разница, если все одно транзакция по этой карте без on-line PIN запрещена?
может быть даже лучше, если терминал сразу откажет (по маске в TVR) чем пойдет на хост за отказом.
Впрочем, если хочется фиксировать все попытки провести операцию… то почему бы и нет.
в общем не однозначно. и то и то имеет право на жизнь.
главное для всех комбинаций в CVM тщательно расписать все сценарии и настойки хоста, что бы случайно не осталось «дырок» и нежелательных вариантов.
Хотя для такой карты сценарий хоста по CVM прост: нет успешной проверки PIN блока — нет транзакции.
А каким софтом Вы такой лог получили?
Приложение карты без DDA|CDA не должна поддерживать off-line PIN вообще. Иначе она легко клонируется.
Банк, выпускающий такие карты сознательно подставляет клиентов. Клиент даже доказать ничего не сможет если что.
Банк, выпускающий такие карты сознательно подставляет клиентов. Клиент даже доказать ничего не сможет если что.
Спасибо коллеге по цеху за добротную статью :)
Хочу только добавить, что не смотря на все спецификации и стандарты, случаются иногда на практике различные нюансы, когда например коряво написанный софт терминала ломает схему использования чип-карт. На практике были случаи, когда сторонний чиповый терминал обслуживал чиповую карту с прописанным в CVM-листе обязательным запросом пин-кода просто по подписи.
Хочу только добавить, что не смотря на все спецификации и стандарты, случаются иногда на практике различные нюансы, когда например коряво написанный софт терминала ломает схему использования чип-карт. На практике были случаи, когда сторонний чиповый терминал обслуживал чиповую карту с прописанным в CVM-листе обязательным запросом пин-кода просто по подписи.
Судя по нашумевшей в узких кругах ситуации с перехватом команды проверки PIN (дополнительный чип на карте).
Ошибки бывают и на ПО хоста.
Интересно, кому в таких случаях идет претензия.
Банку эмитенту который разрешил операцию или вендору ПО через суд…
Как то даже не задумывался, содержит ли лицензия на банковский софт типичную фразу насчет отказа от ответственности при использовании ПО.
Ошибки бывают и на ПО хоста.
Интересно, кому в таких случаях идет претензия.
Банку эмитенту который разрешил операцию или вендору ПО через суд…
Как то даже не задумывался, содержит ли лицензия на банковский софт типичную фразу насчет отказа от ответственности при использовании ПО.
Претензия явно эмитенту (клиент же заключал договор только с эмитентом), а он уже по внутренним договорам (или в суде) будет разбираться с эквайером и ПС.
Но сдается мне, что, если не удастся доказать факт обхода команды VERIFY, виноватым окажется клиент.
Но сдается мне, что, если не удастся доказать факт обхода команды VERIFY, виноватым окажется клиент.
Ситуация когда «карта» а точнее прокси чип, имплантированный в украденную карту, выдал SW:9000 (ok) на проверку off-line PIN, а хост эмитента почему то проигнорировал значение в CVR и подтвердил транзакцию, наверное это проблема разработчиков ПО эмитентского хоста… Ну и банка эмитента заодно.
При этом эквайрер все сделал честно!
При этом эквайрер все сделал честно!
Возможно мне кто-нибудь сможет объяснить мою ситуацию.
Мне выдали карту с возможностью бесконтактной оплаты, но конкретно бесконтактная оплата не работала (терминал или телефон с nfc никак не реагировали на поднесение карты), однако оплата по чипу работала. Я написал заявление в банке, и через несколько дней бесконтактная оплата заработала сама собой (то есть те несколько дней работал все так же только чип, а теперь можно без проблем оплачивать пейпассом).
Выглядело для меня все так, как будто банк удаленно включил на карте возможность бесконтактной оплаты, которая ранее была выключена. Девочка из банка не в курсе всего этого, конечно.
Возможно ли такое управление включением/выключением бесконтактных платежей удаленно банком?
Мне выдали карту с возможностью бесконтактной оплаты, но конкретно бесконтактная оплата не работала (терминал или телефон с nfc никак не реагировали на поднесение карты), однако оплата по чипу работала. Я написал заявление в банке, и через несколько дней бесконтактная оплата заработала сама собой (то есть те несколько дней работал все так же только чип, а теперь можно без проблем оплачивать пейпассом).
Выглядело для меня все так, как будто банк удаленно включил на карте возможность бесконтактной оплаты, которая ранее была выключена. Девочка из банка не в курсе всего этого, конечно.
Возможно ли такое управление включением/выключением бесконтактных платежей удаленно банком?
Да такое возможно. Во многих дуальных картах можно включать/выключать бесконтактную часть приложения настройками карты. При очередной операции в терминале или банкомате, банк мог прислать обновление настроек приложения в скриптовой команде, и таким образом включить бесконтактную часть.
Значит, такое возможно, здорово. Тогда странно, что такое не реализовали как дополнительную функцию (параноики с радостью бы отключили бесконтактный интерфейс).
Раз вы все знаете про карты, я вас еще спрошу. При замене карты мне выдали карту с теме же реквизитами. Я знаю, что сейчас много где выдают карты с теми же номером и сроком действия. Но тут и CVV2-код тоже полностью совпадал с предыдущей картой.
Раньше я думал, что эти 3 цифры (CVV2) генерируются случайно, что-то типа пин-кода. Это мне так повезло или там все по-другому устроено?
Раз вы все знаете про карты, я вас еще спрошу. При замене карты мне выдали карту с теме же реквизитами. Я знаю, что сейчас много где выдают карты с теми же номером и сроком действия. Но тут и CVV2-код тоже полностью совпадал с предыдущей картой.
Раньше я думал, что эти 3 цифры (CVV2) генерируются случайно, что-то типа пин-кода. Это мне так повезло или там все по-другому устроено?
Насчет CVV2 я не скажу. По аналогии с первым СVV (который на магнитной карте) скорее всего в расчете участвуют номер карты и срок действия. На основании этих данных и секретного ключа, по 3DES рассчитывается подпись. Далее нехитрыми манипуляциями получают 3х-значный код. Алгоритмы и данные для разных платежных систем разные и к сожалению я их точно не знаю (и насколько я помню они под NDA).
Код CVV2 (Card Verification Value) высчитывается на основе данных карты, которые статичны. Рассчитывается так же как и CVV, но с немного иным набором входных параметров. Так что если параметры карты у вас не изменились (номер, срок действия), то CVV2 код будет точно такой же.
PSN в рассчете CVV2 не принимает участия?
PIN не принимает участие с расчете CVV2, иначе после любой процедуры смены PIN-кода, у вас менялся бы и CVV2.
К тому же CVV — это Card Verification Value, т.е. защитный код, верифицирующий корректность статических данных самой карты, не зависимо от значения PIN-кода на хосте.
PIN-код участвует в формировании значения PVV — PIN Verification Value, но это уже другая история :)
К тому же CVV — это Card Verification Value, т.е. защитный код, верифицирующий корректность статических данных самой карты, не зависимо от значения PIN-кода на хосте.
PIN-код участвует в формировании значения PVV — PIN Verification Value, но это уже другая история :)
Скажите, почему ПИН-код четыре цифры? Почему цифры — я понимаю, а почему четыре?
Четыре цифры, набранные за 2 секунды запоминаются хоть взглядом, хоть камерой наблюдения. Приходится старательно прикрывать клавиатуру.
Во времена АС Сберкарт я ставил себе 8-значный ПИН код, который набирал на терминале двумя руками меньше секунды.
Четыре цифры, набранные за 2 секунды запоминаются хоть взглядом, хоть камерой наблюдения. Приходится старательно прикрывать клавиатуру.
Во времена АС Сберкарт я ставил себе 8-значный ПИН код, который набирал на терминале двумя руками меньше секунды.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Платежная EMV-карта. Механизмы обеспечения безопасности платежа