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