Комментарии 70
Почему-то не затронута тема банкнот, проскакивающих мимо купюроприемника внутрь банкомата. И да, про тампер интересно вы выразились.
Ну, я больше с программной частью связан. Всех тонкостей не знаю, т.к. работаю только с тем, что в спецификациях написано — а про проскакивание купюр мимо чего-то там, естественно, ничего нет. Вообще, разве это возможно? Ну, если не учитывать неплотно прилегающее устройство. И что такое «тампер»? Не встречал это слово.
Погуглил, понял, что «тампер» — это кнопка супервизора. Но не пойму, что же такого интересного я про нее сказал. Аж прям заинтриговали.
а про проскакивание купюр мимо чего-то там, естественно, ничего нет. Вообще, разве это возможно?Возможно. У меня было такое. Перед выдачей денег в том месте, откуда они, собственно, выходят, должна открываться дверца (я про тот банкомат, с которым это произошло). Вот она или не до конца открылась или что-то ещё, но купюра застряла внутри. Люди, которые снимали деньги после меня тоже не получали свои наличные. Если интересно, могу завтра сфотографировать этот банкомат.
… количество банковских постов увеличивается вдвое :) А вообще спасибо, всегда интересовало, как оно внутри банка работает, да и не одного меня, я думаю.
Про пин наоборот уже ведь не раз было. Как минимум, возможность иметь зеркальный пин делает невозможным байки про «наоборот».
Вот только я ошибочно думал, что это целиком фейк. А оказывается, реально есть :)
Про пин наоборот уже ведь не раз было. Как минимум, возможность иметь зеркальный пин делает невозможным байки про «наоборот».
Вот только я ошибочно думал, что это целиком фейк. А оказывается, реально есть :)
> Как минимум, возможность иметь зеркальный пин
Кстати с такими пинами не встречался ни разу. Говорить то что их не делают не буду, но из ~ 50 пинов что я знаю таких не было. (хотя нужно проверить даст ли банк поменять пин на такой).
Кстати с такими пинами не встречался ни разу. Говорить то что их не делают не буду, но из ~ 50 пинов что я знаю таких не было. (хотя нужно проверить даст ли банк поменять пин на такой).
Хм, где-то говорили, что «банковские сотрудники не должны знать пин код вашей карты» :)
Думаю даст, взять хотя бы стандартный пин-код 0000 на некоторых картах.
Думаю даст, взять хотя бы стандартный пин-код 0000 на некоторых картах.
> банковские сотрудники не должны знать пин код вашей карты
Они и не знают. про ~ 50 я сказал своих (текущих, бывших и тд).
Они и не знают. про ~ 50 я сказал своих (текущих, бывших и тд).
> стандартный пин-код 0000
В наших банках таких пинов нет. Либо ты получаешь пин в конверте, либо ты должен сам активировать карту введя пин в интернет-банкинге (до этого карта не рабочая и банкомат ее скушает сразу же).
В наших банках таких пинов нет. Либо ты получаешь пин в конверте, либо ты должен сам активировать карту введя пин в интернет-банкинге (до этого карта не рабочая и банкомат ее скушает сразу же).
Я говорил касательно ПриватБанка. По разному, если выдают карту как обычно, в конверте и пин-код. Иногда сразу же на терминале просят набрать дважды пин. А как-то менял кредитку, и выдали с нулями предупредив, что хорошо бы сразу в терминале сменить пин на что-то более порядочное.
Видимо везде по разному, и вашими же словами, все настраиваемо.
Видимо везде по разному, и вашими же словами, все настраиваемо.
Может какие-то банки так и делают. В целом ситуации с пинами довольно забавные. Фактически пин никогда не уходит на процессинговый сервер (если единичные исключения. это когда в платежных терминалах вместо хардварной клавиатуры для ввода пина предлагают вводить на сенсорном экране). Хардварная клавиатура не имеет связи с банком (именно по этому при вводе не правльного пина сообщение об этом я получаю только на этапе снятия денег, когда транзакция не прошла). Пин он как nonce работает (если совсем уж образно подумать. транзакция обворачиваеться в какой-то ключ, который дает клавиатура. а клавиатура дает совсем не пин). По этому даже 0000 довольно безопасный пин (пока его никто не знает). А что касается пина в обратном порядке — en.wikipedia.org/wiki/ATM_SafetyPIN_software
Пожалуй, уточню. ПИН, естественно, уходит процессингу, иначе как он сможет его проверить? Другое дело, что он никогда не уходит в чистом виде — он всегда зашифрован рабочим ключом банкомата. А этот ключ может меняться так часто, как нужно. Правда, тут есть некоторые ограничения для некоторых видов банкоматов — например, NDC/DDC необходимо закрыть (перевести в состояние Out-Of-Service), чтобы поменять ключи.
Вы имели ввиду, наверное, что чистый ПИН практически никогда не циркулирует в приложении — если он вводится через ПИН-пад, то он там сразу шифруется и наружу отдается в виде ПИН-блока.
Вы имели ввиду, наверное, что чистый ПИН практически никогда не циркулирует в приложении — если он вводится через ПИН-пад, то он там сразу шифруется и наружу отдается в виде ПИН-блока.
«именно по этому при вводе не правльного пина сообщение об этом я получаю только на этапе снятия денег, когда транзакция не прошла»
Да ладно.
Месяц назад снимал в Сбере, моторная память подсунула не тот пинкод — сразу отказал.
Да ладно.
Месяц назад снимал в Сбере, моторная память подсунула не тот пинкод — сразу отказал.
ПИН-код может проверяться также и локально. Это от настройки сценария зависит.
Пин может проверить еще и emv-чип карты (оффлайн пин). Это обычно используется при офлайн транзакциях в венденговых машинах. Хотя можно и к банкомату прикрутить левой задней. Но, по хоршему, пин нужно проверять после ввода параметров транзакции, так как по стандарту emv решение о вводе или не вводе пина принмает карта на основании этих данных. В банкоматах все транзакции на сегодняшний день онлайновые, так что оффлайновая проверка пина может служить лишь как удобство для пользователя. С другой стороны, это не совсем по стандарту. Не знаю как такие банкоматы проходят сертификацию. Скорее всего, проверяют пин дважды: оффлайн и онлайн способом.
Онлайн ПИН (который отсылается на хост в зашифрованном виде) или оффлайн ПИН (проверяется самой картой без отсылки на хост) — это два разных способа проверки. Банк, выпустивший карточку, определяет, какой из этих способов нужно использовать при каких условиях. Основные условия для выбора — это тип операции и сумма операции.
При выдаче наличных (типичная операция банкомата), как правило, для проверки используется онлайн ПИН.
При покупке товара банк может установить, например, такие правила: покупка на сумму до 1000 руб. проводится без ввода ПИНа, больше 1000 — с проверкой оффлайн ПИН.
Теоретически возможно использовать обе проверки — и онлайн, и оффлайн. В этом случае клиенту придётся вводить ПИН два раза. В реальной жизни, конечно, никто так не делает, но некоторые тестовые наборы карт EMV предусматривают проверку и такого варианта.
При выдаче наличных (типичная операция банкомата), как правило, для проверки используется онлайн ПИН.
При покупке товара банк может установить, например, такие правила: покупка на сумму до 1000 руб. проводится без ввода ПИНа, больше 1000 — с проверкой оффлайн ПИН.
Теоретически возможно использовать обе проверки — и онлайн, и оффлайн. В этом случае клиенту придётся вводить ПИН два раза. В реальной жизни, конечно, никто так не делает, но некоторые тестовые наборы карт EMV предусматривают проверку и такого варианта.
Год/два назад в сбере была подобная ситуация — ошибка была на этапе снятия денег, сейчас же такого не встречал (пин ввожу сразу верный, может и из-за этого)
Кстати с такими пинами не встречался ни разу.
А чего с ними встречаться, подходите к банкомату и хоть 1111 себе пин поставьте :)
А как же возможность сменить пин-код на свой? Двже если не делают специально, то пользователь может задать свой пин-код который будет симметричным.
Мне один раз в Альфе выдали карту с пином 4444 :)
Я думаю, в случае зеркального ПИН-а просто не будет работать функция ложного ПИН-а, если он действительно по умолчанию предлагается как реальный наоборот. Может, если время будет, гляну, как у нас проверка сделана.
Спасибо большое за пост. А вы (или кто-нибудь другой) не могли бы подробнее рассказать про «серверную» часть банковских систем?
Серверная часть есть разная — мониторинг (сколько бумаги в принтере осталось, сколько денег, ошибки и тд), процессинг (транзакции).
Как в принципе такие объемы данных с такими требованиями по надежности обрабатываются? z/TPM?
Насчет серверов обрабатывающих транзакции сказать ничего не могу. Мониторинг сервера это обычные java приложения которые могут как опрашивать банкоматы (по требованию оператора) так и получать от них инфу (кнчилась бумага и банкомат пинганул сервер). Оператор видит только «лампочки» — зеленая/красная (загорелась красная лампочка напротив банкомата по такому-то адресу, значит нужно выслать туда людей). Подробную информацию оператор получает по клику на красную лампочку. (возможно GUI уже поменяли, но было раньше так) Кстати ПО (банкоматов или серверов) всегда проходит в пятницу вечером :)
В банковской сфере почти все на джаве (как минимум, серверная часть).
В нашей системе мониторинг и обработка транзакций выполняются одним и тем же сервером (не физически, конечно, сервер распределенный. То есть не совсем так. Где именно что выполняется — хрен его знает. Программно мониторинг и обработка транзакций — один сервер). Мониторинг — просто один еще модуль сервера :).
Некоторые банкоматы умеют пинговать сервер раз в какой-то промежуток времени (Triton), другие рапортуют только при изменениях (NDC/DDC, Wincor — который является по протоколу клоном первых двух, с небольшими отличиями), у третьих мы сами решаем, что и когда нам слать (банкоматы на платформе Kalignite).
В нашей системе мониторинг и обработка транзакций выполняются одним и тем же сервером (не физически, конечно, сервер распределенный. То есть не совсем так. Где именно что выполняется — хрен его знает. Программно мониторинг и обработка транзакций — один сервер). Мониторинг — просто один еще модуль сервера :).
Некоторые банкоматы умеют пинговать сервер раз в какой-то промежуток времени (Triton), другие рапортуют только при изменениях (NDC/DDC, Wincor — который является по протоколу клоном первых двух, с небольшими отличиями), у третьих мы сами решаем, что и когда нам слать (банкоматы на платформе Kalignite).
Всегда пожалуйста :). Боюсь, ничего про серверную часть рассказать не смогу. Я работал только с эквайрингом, и то, только той его части, которая связана с банкоматами — это настройки банкоматов (свойства, применяемые к ним на серверной части), конфигурации банкоматов (специфические настройки, прогружаемые на банкомат, например, это сценарии взаимодействия), сами банкоматы.
По большему счету, ничего интересного там нет — сплошная нудятина: есть запрос от банкомата, его нужно переложить в транзакционный запрос системы и скормить транзакционному ядру. Потом получить от него ответ и преобразовать в ответ банкомату. Единственное, что тут может быть интересно — это сам механизм описания бинарных сообщений, чтобы с ними было удобно работать. Может, когда-нибудь опишу его подробнее. Сейчас просто нет достаточного материала.
По большему счету, ничего интересного там нет — сплошная нудятина: есть запрос от банкомата, его нужно переложить в транзакционный запрос системы и скормить транзакционному ядру. Потом получить от него ответ и преобразовать в ответ банкомату. Единственное, что тут может быть интересно — это сам механизм описания бинарных сообщений, чтобы с ними было удобно работать. Может, когда-нибудь опишу его подробнее. Сейчас просто нет достаточного материала.
В РБ почти на всех Wincor стоит Windows 2000 (стоял когда я работал в этой сфере). Софт на Java + Flash с привязкой к hasp ключу (для каждого банкомата разный). Есть еще Diebold и NCR (в меньшем количетсве чем Wincor), но их использовала другая контора и что там внутри я не в курсе.
Насчет купюр — разные банкоматы могут выдавать разное количество купюр (фактически зависит от размера «дырки» в диспенсере). Кстати у нас появились банкоматы которые предлагают покупюрный ввод суммы — т.е. я говорю что мне нужно 2 бумажки по 50тр и 2 по 100тр (может в РФ такое уже давно есть).
Насчет купюр — разные банкоматы могут выдавать разное количество купюр (фактически зависит от размера «дырки» в диспенсере). Кстати у нас появились банкоматы которые предлагают покупюрный ввод суммы — т.е. я говорю что мне нужно 2 бумажки по 50тр и 2 по 100тр (может в РФ такое уже давно есть).
У большинства банков, с которыми имел дело (Сити, Райфайзен, Альфа, Промсвязь) чтобы получить размен приходилось вбивать 4500, а иначе все пятитысячными выдавалось. Вот только недавно в Сбере вроде наладили систему, что можно нажать «выдать с разменом» и получить пару бумажек по 500.
Вспоминается случай, как один раз банкомат у работы загрузили по 100 рублей купюрами, вот это были пачки.
Вспоминается случай, как один раз банкомат у работы загрузили по 100 рублей купюрами, вот это были пачки.
У нас почти все банкоматы (даже которые не имеют покупюрного ввода) при вводе суммы показывают какие купюры есть в наличии. т.е. если мне нужно 2млн руб., а я вижу что в банкомате только купюры по 50т.р., то я врядли захочу тут снимать деньги. (40 бумажек) А если у него только по 20т.р. купюры то он даже не даст мне возможности снять 2млн. руб. за один раз (т.к. это 100 бумажек и диспенсер ими подавится :) )
Вот только недавно в Сбере вроде наладили систему, что можно нажать «выдать с разменом» и получить пару бумажек по 500.А можно и не получить. Возможно, это мне так не везло с наличием мелких купюр, но в одном банкомате я уже два раза нарывался на то, что 5000 он выдавал одной купюрой, несмотря на кнопку «с разменом».
По факту этот размен — фигня полная. Снимаешь 5тр, жмёшь с разменом — получаешь одну бумажку. Причем если снять 4900 и 100 — всё нормально снимается. В итоге, как и раньше снимаю по 4900.
Если мне память не изменяет, то именно Diebold умеет выдавать больше чем 40 бумажек (50 или 55)
А можно подробнее про
>Эта фича называется «Ложный ПИН» (iPIN)
Как она у банков называется? По «Ложный ПИН» гуглятся только идеи/предложения и эта статья.
>Эта фича называется «Ложный ПИН» (iPIN)
Как она у банков называется? По «Ложный ПИН» гуглятся только идеи/предложения и эта статья.
Думаю имелся в виду не iPIN (Internet PIN), а SafetyPIN
У нас в системе так и называется :). Ну, может про сокращение iPIN ошибся, и это действительно не Illegal/Invalid PIN, а Internet PIN. Посмотрю, как это поле называется в английской версии.
Мне давно интересно — почему банкоматы не знают сколько у них денег? Точнее вроде как все пишут что информация такая есть, но много раз бывало такое что я прошу сумму, банкомат делает транзакцию, начинает отсчитывать купюры, в процессе говорит хрю-хрю и выплевывает карту. Потом отменяет транзакцию. Это в лучшем случае. Не далее как месяц назад одна развалина при этом еще и ребутнулась. И все. Банк-владелец банкомата промурыжил меня полдня и в результате сказал чтобы я делал чаржбэк в своем банке, что уже небесплатно и это история еще месяца на три с неизвестным результатом. Неужели так сложно глянуть в ячейку памяти прежде чем делать транзакцию?
Во время отсчета может случиться, что одну купюру замяло, или она слиплась с другой, и банкомат отбраковывает всю пачку. Автоматически он не пытается набрать ее заново, а просто посылает на хост аппаратную ошибку о невозможности выдать указанную сумму. А там хост уже может сделать реверс или послать команду на выдачу во второй раз — но для этого ему нужно будет заново пересчитать покупюрную сумму. А она обычно считается во время выполнения транзакции и прикрепляется к ней, так что скорее всего будет реверс.
Также банкомат может послать реверс сам сразу после сообщения о неудачной выдачи. Тут уж реверс придется делать.
Карта у вас вернулась потому, что данный сценарий не различает эту ошибочную ситуацию от любой другой и по сценарию при любой ошибке карту выплевывает от греха подальше (т.к. это могла быть и ошибка CardReader-а). Перезагрузка обычно делается для того, чтобы попытаться исправить ошибку, если она связана с программной частью. Может сценарий у этого был настроен так, что при каждой ошибке он в перезагрузку отправляется, а может ошибка была довольно серъезной. Kalignite, например, так делает.
Другое дело, что если в банкомате физически нет запрошенной суммы на момент начала операции — тогда это косяк создателей сценария — могли бы сразу предупредить об этом.
Может еще быть так, что физически сама сумма есть, но выдать ее имеющимися номиналами невозможно, причем, так как банкомат в большинстве случаев сам не рассчитывает покупюрный расклад, до того, как пошлется запрос на хост, это определить невозможно.
Также банкомат может послать реверс сам сразу после сообщения о неудачной выдачи. Тут уж реверс придется делать.
Карта у вас вернулась потому, что данный сценарий не различает эту ошибочную ситуацию от любой другой и по сценарию при любой ошибке карту выплевывает от греха подальше (т.к. это могла быть и ошибка CardReader-а). Перезагрузка обычно делается для того, чтобы попытаться исправить ошибку, если она связана с программной частью. Может сценарий у этого был настроен так, что при каждой ошибке он в перезагрузку отправляется, а может ошибка была довольно серъезной. Kalignite, например, так делает.
Другое дело, что если в банкомате физически нет запрошенной суммы на момент начала операции — тогда это косяк создателей сценария — могли бы сразу предупредить об этом.
Может еще быть так, что физически сама сумма есть, но выдать ее имеющимися номиналами невозможно, причем, так как банкомат в большинстве случаев сам не рассчитывает покупюрный расклад, до того, как пошлется запрос на хост, это определить невозможно.
И еще интересно как некоторые банки умудряются отказывать в обслуживании по некоторым картам? Всегда снимал в Минске доллары в Приоре — давал по 400 за раз, в этом году — не дает и все. Нисколько. В любом их банкомате. Но белрубли — выдает нормально, а все другие банки с той же карты нормально выдают и доллары. И такое было еще раз в Смоленске — в какой-то момент Смоленский банк, земля ему пухом, тоже перестал выдавать доллары по этой карте. Прослеживается явная тенденция когда банки перестают любить какие-то определенные карты.
Может у этих банкоматов просто-напросто нет долларовых купюр?)
Тут все зависит от наличия долларов в банкомате. И не все банкоматы настроены на выдачу долларов по всем картам. Так же от карты зависит и сумма за раз. Например в Приоре если использовать валютную карту Приора можно и 1000 за раз попросить, а если карта другого банка то максимум 200 (400 уже нигде не осталось). По иностранным картам он может даже не предложить выдачу валюты.
И еще интересно )) кто зарабатывает на валютной конвертации? Только платежная система?
Банк обслуживающий банкомат устанавливает курсы. Вторая таблица
Сомнительное утверждение. По данной ссылке это инфа для клиентов банка, можешь свои доллары снять в рубли в родном же банкомате и не мучить кассира.
Сколько раз снимал рубли или кроны — курс одинаковый в банкоматах всей страны, что наводит мысль на платежную систему. К тому же последнее время банки решили тоже на этом заработать и вылезти вперед, т.к. клиент общается с их железкой и банкоматы стали предлагать — а давай я с твоего счета спрошу не 10000 крон, а прям доллары. Вот только курс который предлагают они — вообще конский. Никогда не надо соглашаться! 3% — от платежной системы после этого кажутся манной небесной. Такое еще кстати стали практиковать в duty free при покупке. Тот же развод.
Сколько раз снимал рубли или кроны — курс одинаковый в банкоматах всей страны, что наводит мысль на платежную систему. К тому же последнее время банки решили тоже на этом заработать и вылезти вперед, т.к. клиент общается с их железкой и банкоматы стали предлагать — а давай я с твоего счета спрошу не 10000 крон, а прям доллары. Вот только курс который предлагают они — вообще конский. Никогда не надо соглашаться! 3% — от платежной системы после этого кажутся манной небесной. Такое еще кстати стали практиковать в duty free при покупке. Тот же развод.
нет, банк-владелец банкомата даже не знает в какой валюте у Вас карта )
Так что курсы устанавливать он тем более не может ))
Так что курсы устанавливать он тем более не может ))
На уровне «чайников» начинющих вкуривать тему нормально, разве что уточнить:
п.2 Банк не знает ПИН-код клиентов. Это так если ПО процессинга корректное -соответствующее PCI DSS. По этому переворачиавй его, не переворачивай это все одно и тоже секретное значенеи в голове клиента. Реально ПИНкода это не обязательно 4 цифры.
п.3 На начальном этапе обработки карты ПО банкомата читает номер карты и по ее первым цифрам (это не обязательно BIN) может глобально переключится на ветку в сценарии работы и настроек. Т.е. если вы для примера знаете что для карт начинающихся с 445566 это японские карты то наверно японцам будет приятно увидеть иероглифы и не видеть дробную часть сумм.
Соответственно если это служебные карты — то тут могут появится специальные служебные элементы для инкассаторов или технических специалистов.
Но администраторы сценариев банкоматов очень ленивые FIT-таблицы практически не используются.
п.4 В принципе да, но я бы разделил ПО для банкоматов по другому. Есть ПО которое:
— обменивается с хостом по протоколам NDC/DDC
— обменивается по самописному протоколу (для примера когда то так было в системе UnionCard)
Первый вариант он более универсальный по типу подключения к процессингу, но ограниченный по визуальным возможностям и различным вкусностям в логику, и есть требования к кланам связи.
Второй жестоко привязан к конкретному процессиингу, но реально может предъявлять смешные требования каналам связи. Реально возможно отправить в процессинг и принять из процессинга всего по 1-ой СМС. Вот и вся транзакция. Хотя в основе опять же лежит использования библиотек NDC/DDC но локально на банкомате.
п.2 Банк не знает ПИН-код клиентов. Это так если ПО процессинга корректное -соответствующее PCI DSS. По этому переворачиавй его, не переворачивай это все одно и тоже секретное значенеи в голове клиента. Реально ПИНкода это не обязательно 4 цифры.
п.3 На начальном этапе обработки карты ПО банкомата читает номер карты и по ее первым цифрам (это не обязательно BIN) может глобально переключится на ветку в сценарии работы и настроек. Т.е. если вы для примера знаете что для карт начинающихся с 445566 это японские карты то наверно японцам будет приятно увидеть иероглифы и не видеть дробную часть сумм.
Соответственно если это служебные карты — то тут могут появится специальные служебные элементы для инкассаторов или технических специалистов.
Но администраторы сценариев банкоматов очень ленивые FIT-таблицы практически не используются.
п.4 В принципе да, но я бы разделил ПО для банкоматов по другому. Есть ПО которое:
— обменивается с хостом по протоколам NDC/DDC
— обменивается по самописному протоколу (для примера когда то так было в системе UnionCard)
Первый вариант он более универсальный по типу подключения к процессингу, но ограниченный по визуальным возможностям и различным вкусностям в логику, и есть требования к кланам связи.
Второй жестоко привязан к конкретному процессиингу, но реально может предъявлять смешные требования каналам связи. Реально возможно отправить в процессинг и принять из процессинга всего по 1-ой СМС. Вот и вся транзакция. Хотя в основе опять же лежит использования библиотек NDC/DDC но локально на банкомате.
п.2 Банк не знает ПИН-код клиентов.
Конечно. Но что мешает хранить два ПИН-блока (зашифрованных ПИН) — верный и ложный? Когда приходит ПИН-блок от банкомата, проверяем его сначала на равенство верному, если не прошло — на равенство ложному. Если и так не прошло, значит вообще левый.
п.4 В принципе да, но я бы разделил ПО для банкоматов по другому.
Ну если делить по протоколам, то надо каждый вид банкомата в отдельную группу выводить. Я же постарался сделать разделение по фундаментальному признаку.
п.3 На начальном этапе обработки карты ПО банкомата читает номер карты и по ее первым цифрам (это не обязательно BIN) может глобально переключится на ветку в сценарии работы и настроек.
Дополню. Тут даже не обязательно, чтобы это переключение делал банкомат. Протокол NDC/DDC также позволяет в любом ответе обновить экраны, которые банкомат показывает — но для поддержки локализации это, естественно, хуже, чем один раз загрузить все нужные экраны и просто выбирать нужные на стороне банкомата. В случае инкассации транзакция уйдет в процессинг как обычно, а он уже выдаст команду на закрытие и прочее, необходимое для инкассации.
Но администраторы сценариев банкоматов очень ленивые FIT-таблицы практически не используются.
Думаю, тут дело в том, что таких клиентов очень мало. Да и сценарии банк в основном не пишет сам с нуля, а максимум, чуток подгоняет под себя — он же не держит у себя людей для этой цели — сценарий один раз написал и он работает. Например, базовые сценарии мы сами предоставляем, да еще и сопровождаем (за денюжку, я думаю).
Упаси боже Вас хранить зашифрованный ПИН блок!!! За это надо сразу на месте расстреливать весь технический персонал разработчиков и процессинга! И вот почему.
Пусть в вас есть функция 3DES(K, P). По умолчанию предусмотрено всего 5 значений ключа K и длина пин-кода 4 цифр. Допускаем что у вас всего 50 000 клиентов. В лучшем случаи имеем что у вас 50 000 шифрованных пин-блоков. А теперь вуа-ля! И вас появилось еще 50 тыс. Клиентов т.к. у вас уже по 2 одинаоквых пин-блока в базе!
А теперь о плохом. Чаще всего используется только 1 ключ K по этому у вас уже не 50 000, а 10 000 уникальных значений. Да и генератор случайных цифр в HSM генерирует именно случайные числа поэтому уже на 3 000 клиентов у вас будет гарантированно 2 одинаковых пин-кодоа -> пин-блока. А теперь представь какая радость это для администратора БД с базой размером в 100-200 тыс. клиентов. Т.е. ПИН-код становится известным очень широкому кругу лиц.
Поэтому ни ПИН-блок и не ПИН-код не хранятся. А хранится так называемое PVV — это по сути односторонняя функция от K и P. Да и что самое прикольное оно PVV хранится на карте на магнитной полосе или чипе. А ключ К хранится в безопасном виде в HSM процессинга. Но елси хранить PVV на карте то становится сложно реализовывать механизм смны ПИН-кода.
Т.е. примерно так.
Тема не объятая, в одном посте не расскажешь.
Пусть в вас есть функция 3DES(K, P). По умолчанию предусмотрено всего 5 значений ключа K и длина пин-кода 4 цифр. Допускаем что у вас всего 50 000 клиентов. В лучшем случаи имеем что у вас 50 000 шифрованных пин-блоков. А теперь вуа-ля! И вас появилось еще 50 тыс. Клиентов т.к. у вас уже по 2 одинаоквых пин-блока в базе!
А теперь о плохом. Чаще всего используется только 1 ключ K по этому у вас уже не 50 000, а 10 000 уникальных значений. Да и генератор случайных цифр в HSM генерирует именно случайные числа поэтому уже на 3 000 клиентов у вас будет гарантированно 2 одинаковых пин-кодоа -> пин-блока. А теперь представь какая радость это для администратора БД с базой размером в 100-200 тыс. клиентов. Т.е. ПИН-код становится известным очень широкому кругу лиц.
Поэтому ни ПИН-блок и не ПИН-код не хранятся. А хранится так называемое PVV — это по сути односторонняя функция от K и P. Да и что самое прикольное оно PVV хранится на карте на магнитной полосе или чипе. А ключ К хранится в безопасном виде в HSM процессинга. Но елси хранить PVV на карте то становится сложно реализовывать механизм смны ПИН-кода.
Т.е. примерно так.
Тема не объятая, в одном посте не расскажешь.
Очень интересно было бы послушать описание механизмов безопасности с объяснением, почему сделано так; вот как вы сейчас рассказали. А то ведь мало знать механизмы, нужно понимать, зачем они были придуманы.
Ну и принципиально процедуру проверки это не меняет. Кстати, хранятся у нас действительно PVV, о чем в названиях полей написано. Просто не знал таких тонкостей, поэтому рассказал так, чтобы понятно всем было.
Ну и принципиально процедуру проверки это не меняет. Кстати, хранятся у нас действительно PVV, о чем в названиях полей написано. Просто не знал таких тонкостей, поэтому рассказал так, чтобы понятно всем было.
длина пин-кода 4 цифр
Вообще, по стандарту от 4 до 12, но молодежь нынче часто об этом забывает.
А теперь о плохом. Чаще всего используется только 1 ключ K
Так на втором же треке пишется PVV и номер оригинального ключа из HSM, которым он пользовался в процессе рождения реквизитов.
Но елси хранить PVV на карте то становится сложно реализовывать механизм смны ПИН-кода.
Да проще простого. Для нового ПИНа, а также любого другого, в т. ч. «ложнго», в базе тупо хранят разницу с оригинальным. Соответственно, приходит ПИН-блок, мы оттуда выковыриваем ПИН, добавляем нужное значение, считаем PVV, сравниваем.
Не большое уточнение пишется не номер ключа, а его индекс (PVKI) ) для операций с ПИН-ом. Да и как верно подметили настройки на карте в базе процессинга, могут перекрыть как PVV (смена ПИНа), так же можно перекрыть и PVKI. Теоретически можно использовать уникальный key для каждой карты, но уж больно это затратно.
А если посмотреть на всю историю криптографии и безопасности в платежных систем это всегда «борьба жить на широкую ногу, с очень скромными возможностями по факту». Ограничения по поддержке старого оборудования, стандартов и т.п…
Проблема хранения шифрованного ПИН-блока и PVV заключается в том что
Pin-block=3DES(Key, pin)
PVV= PVV(Key, pin, pan, expdate)
Т.е. есть для PVV гарантируется, что они различны для двух одинаковых ПИН-ов
Да и сама функция PVV по идее односторонняя. Хотя в ней есть свои криптографические скелеты.
А если посмотреть на всю историю криптографии и безопасности в платежных систем это всегда «борьба жить на широкую ногу, с очень скромными возможностями по факту». Ограничения по поддержке старого оборудования, стандартов и т.п…
Проблема хранения шифрованного ПИН-блока и PVV заключается в том что
Pin-block=3DES(Key, pin)
PVV= PVV(Key, pin, pan, expdate)
Т.е. есть для PVV гарантируется, что они различны для двух одинаковых ПИН-ов
Да и сама функция PVV по идее односторонняя. Хотя в ней есть свои криптографические скелеты.
Вот интересно, как можно использовать функцию «ПИН код наоборот, если ПИН код зеркальный? Например, 1221. Или же такие ПИН коды принципиально не формируются при выдаче карт?
Небольшое продолжение по возникшим вопросам — geektimes.ru/post/258978
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Банкомат. По ту сторону провода