Пользователь
0,0
рейтинг
28 марта 2014 в 23:31

Разработка → Банкомат. По ту сторону провода из песочницы

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

Так как это моя первая статья на хабре, прошу прощения за, возможно, излишнюю сумбурность.

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

1. Карты и счета


Один из форумчан, ссылаясь на свой опыт, настаивал, что к карте можно привязать любой счет (причем в любой валюте) за 5 минут, кто-то другой сомневался. Это действительно так. Возможность этой процедуры определяется только возможностями программного обеспечения самой процессинговой системы, поддержкой ее со стороны интернет/мобильного банка, желанием банка предоставлять населению такие услуги и его желанием заплатить за это дополнительную денежку разработчику системы. В системе, к разработке которой я имею отношение, карта и счет — это две разные сущности.
Карта в нашей терминологии является токеном — точно также, как токеном является, например, пароль, сертификат, документ, удостоверяющий личность и некоторые другие, сходу не вспомню. Токен служит лишь для доступа к счету. Причем, как к счету можно получить доступ через несколько токенов, так и токен может обслуживать несколько счетов. Например, в одном банке, где работает наша система, во время карточной операции вас могут попросить указать конкретный счет — если к карте их привязано несколько.

2. ПИН наоборот для мошенников


Эта фича называется «Ложный ПИН» (iPIN). То, что какой-то банк предлагает по умолчанию делать его, как основной ПИН, записанный наоборот, служит только цели более легкого его запоминания. Судя по комментариям, у меня сложилось впечатление, что не все это понимают.
Насколько я слышал от коллег, эта фича не очень востребована, т.к. имеет свои негативные стороны (не знаю, какие). Факт в том, что используется она крайне редко.

3. Карточки инкассаторов/супервизоров


Опять же, это не непреложное правило, это сделано просто для удобства обслуживания. В нашей системе оно сделано таким образом, подозреваю, что во всех остальных так же:
При вставке такой карточки хост, вместо выполнения транзакции, запрашивает у банкомата текущие счетчики (либо приложение банкомата само может определить такую карту и самостоятельно сразу послать счетчики — о приложениях дальше). Далее происходит физическая инкассация терминала с занесением в него новых счетчиков (это делается вручную, но я краем уха слышал, что возможно и автоматическое занесение по опросу кассет… но мне кажется, сейчас это редко где есть). После закрытия банкомата дверца придавливает специальную кнопку, называемой кнопкой супервизора, и банкомат рапортует в сеть как минимум, что изменилось состояние сенсора «режим супервизора», как максимум — свое полное состояние, в том числе и новые счетчики (а может еще и старые — см. в главе про приложения). Если рапорт содержит информацию только о сенсоре, то хост самостоятельно запрашивает счетчики. В этот момент хост может сравнить новые счетчики со старыми и создать транзакцию инкассации. Опять же, повторюсь, так это работает у нас, но это не значит, что так работает везде. Но так как схема очень гибкая и автономная, то используется наверняка почти в любом программном продукте такого рода.

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

4. Приложение на банкомате


Тут надо отметить, что все приложения можно разделить на 2 вида:
  • протокол обмена жестко определен, на стороне банкомата выполняется программа, работающая по этому протоколу и расширить ее никак нельзя. Это, например, NDC, DDC и Triton.
  • протокол обмена не только жестко не закреплен, но наоборот, приложение на банкомате является расширяемым плагином для поддержки общения с конкретным хостом. Так устроены банкоматы Kalignite — кстати, наиболее гибкие из тех, с которыми мне довелось работать. Приложение Kalignite — это обычное .Net приложение, показываемые на экране банкомата экраны — обычные HTML-странички, отображаемые через стандартный .Net компонент браузера (который, в свою очередь, основан на ядре IE, т.е. имеет все его уязвимости. Однако сам компонент сильно урезан). Благодаря этому разработкой визуальной части сценария могут заниматься веб-дизайнеры и пользоваться всеми благами — например, jQuery, виртуальной клавиатурой и всем, чего душа пожелает.
    Так как на банкомате работает код, который пишется самим разработчиком системы, то выполнение всяких сервисных функций может заметно упроститься — например, транзакцию инкассации можно сформировать на самом банкомате, и переслать ее на хост, как обычный запрос транзакции (только это будет административная транзакция).

Самое же главное, что отличает эти схемы взаимодействия хоста с банкоматом является то, какая сторона хранит промежуточные данные до тех пор, пока не сможет сформироваться полноценная транзакция. Это может произойти, например, в том случае, когда к карте привязано 2 и более счетов — т.к. сценарий взаимодействия не знает количество счетов заранее, он просто формирует запрос транзакции и отсылает ее на хост. Хост ее отклоняет с причиной «Необходимо уточнение» и присылает список параметров, которые необходимо уточнить. И тут возможно два варианта:
  • терминал присылает только уточненные параметры — в таком случае, хост должен где-то хранить информацию, которую банкомат прислал в предыдущем запросе — банкомат stateless, хост statefull — так ведут себя все банкоматные программы с жестко закрепленным протоколом (NDC/DDC, Triton и другие), т.к. протокол не предусматривает места для хранения этих данных;
  • терминал присылает все прошлые данные плюс уточненные параметры — банкомат statefull, хост stateless. Так лучше делать при работе с Kalignite, т.к. все равно нужно (желательно) написать свое расширение для взаимодействия по удобному хосту протоколу.

5. Изъятие карт и неверные ПИНы


Поведение при обнаружении не забранной карты полностью настраивается — банкомат может как захватить ее, так и оставить в тракте. Тоже самое относится к выдаче карты до/после денег, в начале/конце работы, при отключении электричества (если банк не совсем бедный, в банкомате должен быть ИБП). Что делать, если введен неверный ПИН-код, введен ложный ПИН (если есть), когда обнуляется счетчик неверных ПИН, нужен ли захват карты — все решает хост. Если хост не проинструктирует банкомат захватить карту, он ее не захватит, будь она хоть десять раз фальшивая, украденная и потерянная.

6. Чиповые карты


Что делать с чиповыми картами, если не удалось прочитать чип — зависит от настроек сценария. Может предлагаться более узкий круг услуг, а может просто отказать обслуживать. Тоже самое касается карт других банков.

7. Максимум в 40 купюр для выдачи и алгоритм выдачи


Какой алгоритм выдачи использовать и откуда банкомат его узнает — опять же, полностью зависит от настройки. Конечно, сейчас, в эпоху повального интернета, хосту выгоднее самому выполнять все расчеты, а банкомату только выдавать команды. Однако, например, Kaliginte-объект для управления CashDispenser-ом (устройством выдачи наличных) также умеет рассчитывать покупюрную сумму выдачи по разным алгоритмам. В нашей системе мы не используем эту возможность. Опять же, позволять пользователю выбрать алгоритм выдачи, или, как кто-то говорил в комментариях, даже конкретные номиналы купюр — целиком и полностью зависит от желания банка создать такой сценарий (ну и от возможностей ПО, конечно же).

Ограничение в 40 купюр действительно идет от физических ограничений — пачка из 40 банкнот почти в сантиметр толщиной. Про то, что банкомат просто откажет выдавать сумму, которая не сможет быть физически выдана за раз, с невразумительной ошибкой — вина разработчика сценария — что не предусмотрел внятного сообщения о причине. С Kalignite-ом все вообще просто, это обычный HTML, как я уже выше говорил, фактически локальный сайт, а для NDC/DDC банкоматов ответ хоста может содержать обновленные экраны, текст на которых, опять же, определяет хост… Протокол Triton-а победнее, да и кодов ошибок у него мало, но Triton-ы в России, кажется, не очень распространены.

8. Операционная система


На тех, на которых мне доводилось тестироваться, стоит Windows XP. А тестировался я с Kalignite-овским сценарием, с NDC и DDC банкоматами.



Ну вот. Надеюсь, было интересно и хаоса в головах поубавилось. Основная мысль, которую я хотел донести — настраивается абсолютно ВСЕ. Естественно, где-то меньше, где-то больше, но это больше касается уже более глубоких нюансов, чем те, что видны с первого взгляда.
@Mingun
карма
32,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (70)

  • 0
    Почему-то не затронута тема банкнот, проскакивающих мимо купюроприемника внутрь банкомата. И да, про тампер интересно вы выразились.
    • 0
      Ну, я больше с программной частью связан. Всех тонкостей не знаю, т.к. работаю только с тем, что в спецификациях написано — а про проскакивание купюр мимо чего-то там, естественно, ничего нет. Вообще, разве это возможно? Ну, если не учитывать неплотно прилегающее устройство. И что такое «тампер»? Не встречал это слово.
      • 0
        Погуглил, понял, что «тампер» — это кнопка супервизора. Но не пойму, что же такого интересного я про нее сказал. Аж прям заинтриговали.
      • +1
        а про проскакивание купюр мимо чего-то там, естественно, ничего нет. Вообще, разве это возможно?
        Возможно. У меня было такое. Перед выдачей денег в том месте, откуда они, собственно, выходят, должна открываться дверца (я про тот банкомат, с которым это произошло). Вот она или не до конца открылась или что-то ещё, но купюра застряла внутри. Люди, которые снимали деньги после меня тоже не получали свои наличные. Если интересно, могу завтра сфотографировать этот банкомат.
        • +1
          Или там был приклеен двухсторонний скотч.
  • 0
    … количество банковских постов увеличивается вдвое :) А вообще спасибо, всегда интересовало, как оно внутри банка работает, да и не одного меня, я думаю.

    Про пин наоборот уже ведь не раз было. Как минимум, возможность иметь зеркальный пин делает невозможным байки про «наоборот».
    Вот только я ошибочно думал, что это целиком фейк. А оказывается, реально есть :)
    • 0
      > Как минимум, возможность иметь зеркальный пин

      Кстати с такими пинами не встречался ни разу. Говорить то что их не делают не буду, но из ~ 50 пинов что я знаю таких не было. (хотя нужно проверить даст ли банк поменять пин на такой).
      • 0
        Хм, где-то говорили, что «банковские сотрудники не должны знать пин код вашей карты» :)
        Думаю даст, взять хотя бы стандартный пин-код 0000 на некоторых картах.
        • 0
          > банковские сотрудники не должны знать пин код вашей карты

          Они и не знают. про ~ 50 я сказал своих (текущих, бывших и тд).
        • 0
          > стандартный пин-код 0000

          В наших банках таких пинов нет. Либо ты получаешь пин в конверте, либо ты должен сам активировать карту введя пин в интернет-банкинге (до этого карта не рабочая и банкомат ее скушает сразу же).
          • 0
            Я говорил касательно ПриватБанка. По разному, если выдают карту как обычно, в конверте и пин-код. Иногда сразу же на терминале просят набрать дважды пин. А как-то менял кредитку, и выдали с нулями предупредив, что хорошо бы сразу в терминале сменить пин на что-то более порядочное.

            Видимо везде по разному, и вашими же словами, все настраиваемо.
            • +1
              Может какие-то банки так и делают. В целом ситуации с пинами довольно забавные. Фактически пин никогда не уходит на процессинговый сервер (если единичные исключения. это когда в платежных терминалах вместо хардварной клавиатуры для ввода пина предлагают вводить на сенсорном экране). Хардварная клавиатура не имеет связи с банком (именно по этому при вводе не правльного пина сообщение об этом я получаю только на этапе снятия денег, когда транзакция не прошла). Пин он как nonce работает (если совсем уж образно подумать. транзакция обворачиваеться в какой-то ключ, который дает клавиатура. а клавиатура дает совсем не пин). По этому даже 0000 довольно безопасный пин (пока его никто не знает). А что касается пина в обратном порядке — en.wikipedia.org/wiki/ATM_SafetyPIN_software
              • +3
                Пожалуй, уточню. ПИН, естественно, уходит процессингу, иначе как он сможет его проверить? Другое дело, что он никогда не уходит в чистом виде — он всегда зашифрован рабочим ключом банкомата. А этот ключ может меняться так часто, как нужно. Правда, тут есть некоторые ограничения для некоторых видов банкоматов — например, NDC/DDC необходимо закрыть (перевести в состояние Out-Of-Service), чтобы поменять ключи.

                Вы имели ввиду, наверное, что чистый ПИН практически никогда не циркулирует в приложении — если он вводится через ПИН-пад, то он там сразу шифруется и наружу отдается в виде ПИН-блока.
                • 0
                  > сразу шифруется и наружу отдается в виде ПИН-блока.

                  Ага
              • 0
                «именно по этому при вводе не правльного пина сообщение об этом я получаю только на этапе снятия денег, когда транзакция не прошла»
                Да ладно.
                Месяц назад снимал в Сбере, моторная память подсунула не тот пинкод — сразу отказал.
                • 0
                  ПИН-код может проверяться также и локально. Это от настройки сценария зависит.
                • +2
                  Пин может проверить еще и emv-чип карты (оффлайн пин). Это обычно используется при офлайн транзакциях в венденговых машинах. Хотя можно и к банкомату прикрутить левой задней. Но, по хоршему, пин нужно проверять после ввода параметров транзакции, так как по стандарту emv решение о вводе или не вводе пина принмает карта на основании этих данных. В банкоматах все транзакции на сегодняшний день онлайновые, так что оффлайновая проверка пина может служить лишь как удобство для пользователя. С другой стороны, это не совсем по стандарту. Не знаю как такие банкоматы проходят сертификацию. Скорее всего, проверяют пин дважды: оффлайн и онлайн способом.
                  • 0
                    Онлайн ПИН (который отсылается на хост в зашифрованном виде) или оффлайн ПИН (проверяется самой картой без отсылки на хост) — это два разных способа проверки. Банк, выпустивший карточку, определяет, какой из этих способов нужно использовать при каких условиях. Основные условия для выбора — это тип операции и сумма операции.

                    При выдаче наличных (типичная операция банкомата), как правило, для проверки используется онлайн ПИН.

                    При покупке товара банк может установить, например, такие правила: покупка на сумму до 1000 руб. проводится без ввода ПИНа, больше 1000 — с проверкой оффлайн ПИН.

                    Теоретически возможно использовать обе проверки — и онлайн, и оффлайн. В этом случае клиенту придётся вводить ПИН два раза. В реальной жизни, конечно, никто так не делает, но некоторые тестовые наборы карт EMV предусматривают проверку и такого варианта.
                    • 0
                      Эм, об этом выше и написал. Или вы решили дополнить? :)
                • 0
                  Год/два назад в сбере была подобная ситуация — ошибка была на этапе снятия денег, сейчас же такого не встречал (пин ввожу сразу верный, может и из-за этого)
      • +1
        Кстати с такими пинами не встречался ни разу.

        А чего с ними встречаться, подходите к банкомату и хоть 1111 себе пин поставьте :)
      • 0
        А как же возможность сменить пин-код на свой? Двже если не делают специально, то пользователь может задать свой пин-код который будет симметричным.
      • 0
        Мне один раз в Альфе выдали карту с пином 4444 :)
    • 0
      Я думаю, в случае зеркального ПИН-а просто не будет работать функция ложного ПИН-а, если он действительно по умолчанию предлагается как реальный наоборот. Может, если время будет, гляну, как у нас проверка сделана.
  • 0
    Спасибо большое за пост. А вы (или кто-нибудь другой) не могли бы подробнее рассказать про «серверную» часть банковских систем?
    • 0
      Серверная часть есть разная — мониторинг (сколько бумаги в принтере осталось, сколько денег, ошибки и тд), процессинг (транзакции).
      • 0
        Как в принципе такие объемы данных с такими требованиями по надежности обрабатываются? z/TPM?
        • 0
          Насчет серверов обрабатывающих транзакции сказать ничего не могу. Мониторинг сервера это обычные java приложения которые могут как опрашивать банкоматы (по требованию оператора) так и получать от них инфу (кнчилась бумага и банкомат пинганул сервер). Оператор видит только «лампочки» — зеленая/красная (загорелась красная лампочка напротив банкомата по такому-то адресу, значит нужно выслать туда людей). Подробную информацию оператор получает по клику на красную лампочку. (возможно GUI уже поменяли, но было раньше так) Кстати ПО (банкоматов или серверов) всегда проходит в пятницу вечером :)
          • +1
            В банковской сфере почти все на джаве (как минимум, серверная часть).

            В нашей системе мониторинг и обработка транзакций выполняются одним и тем же сервером (не физически, конечно, сервер распределенный. То есть не совсем так. Где именно что выполняется — хрен его знает. Программно мониторинг и обработка транзакций — один сервер). Мониторинг — просто один еще модуль сервера :).

            Некоторые банкоматы умеют пинговать сервер раз в какой-то промежуток времени (Triton), другие рапортуют только при изменениях (NDC/DDC, Wincor — который является по протоколу клоном первых двух, с небольшими отличиями), у третьих мы сами решаем, что и когда нам слать (банкоматы на платформе Kalignite).
            • 0
              Нет на все на Java.
              Вы слышали про Floraware? или F++?
              На этом чуде языке релизуются одно из довольно популярных решний процессинга. Причем все разработчики из России.
              • 0
                Не только слышал, даже видел :) Краем глаза. Ну и я сказал слово почти. Кроме того, кажется это переделанный компилятор Java.
                • 0
                  Нет это не компилятор java
    • 0
      Всегда пожалуйста :). Боюсь, ничего про серверную часть рассказать не смогу. Я работал только с эквайрингом, и то, только той его части, которая связана с банкоматами — это настройки банкоматов (свойства, применяемые к ним на серверной части), конфигурации банкоматов (специфические настройки, прогружаемые на банкомат, например, это сценарии взаимодействия), сами банкоматы.

      По большему счету, ничего интересного там нет — сплошная нудятина: есть запрос от банкомата, его нужно переложить в транзакционный запрос системы и скормить транзакционному ядру. Потом получить от него ответ и преобразовать в ответ банкомату. Единственное, что тут может быть интересно — это сам механизм описания бинарных сообщений, чтобы с ними было удобно работать. Может, когда-нибудь опишу его подробнее. Сейчас просто нет достаточного материала.
  • +1
    В РБ почти на всех Wincor стоит Windows 2000 (стоял когда я работал в этой сфере). Софт на Java + Flash с привязкой к hasp ключу (для каждого банкомата разный). Есть еще Diebold и NCR (в меньшем количетсве чем Wincor), но их использовала другая контора и что там внутри я не в курсе.

    Насчет купюр — разные банкоматы могут выдавать разное количество купюр (фактически зависит от размера «дырки» в диспенсере). Кстати у нас появились банкоматы которые предлагают покупюрный ввод суммы — т.е. я говорю что мне нужно 2 бумажки по 50тр и 2 по 100тр (может в РФ такое уже давно есть).
    • 0
      У большинства банков, с которыми имел дело (Сити, Райфайзен, Альфа, Промсвязь) чтобы получить размен приходилось вбивать 4500, а иначе все пятитысячными выдавалось. Вот только недавно в Сбере вроде наладили систему, что можно нажать «выдать с разменом» и получить пару бумажек по 500.

      Вспоминается случай, как один раз банкомат у работы загрузили по 100 рублей купюрами, вот это были пачки.
      • +2
        У нас почти все банкоматы (даже которые не имеют покупюрного ввода) при вводе суммы показывают какие купюры есть в наличии. т.е. если мне нужно 2млн руб., а я вижу что в банкомате только купюры по 50т.р., то я врядли захочу тут снимать деньги. (40 бумажек) А если у него только по 20т.р. купюры то он даже не даст мне возможности снять 2млн. руб. за один раз (т.к. это 100 бумажек и диспенсер ими подавится :) )
        • +32
          Долго думал над суммами
          • +3
            Да, в РБ они все такие вот богачи.
      • 0
        Вот только недавно в Сбере вроде наладили систему, что можно нажать «выдать с разменом» и получить пару бумажек по 500.
        А можно и не получить. Возможно, это мне так не везло с наличием мелких купюр, но в одном банкомате я уже два раза нарывался на то, что 5000 он выдавал одной купюрой, несмотря на кнопку «с разменом».
        • 0
          Я в таких случаях просто реквестирую суммы вроде 4950.
          • 0
            Я тоже. Просто как ввели эту функцию, решил было, что можно не париться с набиванием некрулгых сумм, а по факту оказалось, что не всегда работает.
            • +2
              Там есть примечание, что-то типа «Размен выдается только про сумме снятия выше 5000 рублей». При меньших суммах — выдаются максимальными купюрами.
              • 0
                Возможно, зависит от банкомата. Мне ни разу такого сообщения не попадалось. Но спасибо за информацию.
      • 0
        По факту этот размен — фигня полная. Снимаешь 5тр, жмёшь с разменом — получаешь одну бумажку. Причем если снять 4900 и 100 — всё нормально снимается. В итоге, как и раньше снимаю по 4900.
    • 0
      Если мне память не изменяет, то именно Diebold умеет выдавать больше чем 40 бумажек (50 или 55)
      • 0
        Да, в последних спеках, что я видел (за 2012 год) написано, что у некоторых серий максимальный размер поднят до 50.
  • +1
    А можно подробнее про
    >Эта фича называется «Ложный ПИН» (iPIN)
    Как она у банков называется? По «Ложный ПИН» гуглятся только идеи/предложения и эта статья.
    • –1
      Думаю имелся в виду не iPIN (Internet PIN), а SafetyPIN
    • 0
      У нас в системе так и называется :). Ну, может про сокращение iPIN ошибся, и это действительно не Illegal/Invalid PIN, а Internet PIN. Посмотрю, как это поле называется в английской версии.
  • 0
    Мне давно интересно — почему банкоматы не знают сколько у них денег? Точнее вроде как все пишут что информация такая есть, но много раз бывало такое что я прошу сумму, банкомат делает транзакцию, начинает отсчитывать купюры, в процессе говорит хрю-хрю и выплевывает карту. Потом отменяет транзакцию. Это в лучшем случае. Не далее как месяц назад одна развалина при этом еще и ребутнулась. И все. Банк-владелец банкомата промурыжил меня полдня и в результате сказал чтобы я делал чаржбэк в своем банке, что уже небесплатно и это история еще месяца на три с неизвестным результатом. Неужели так сложно глянуть в ячейку памяти прежде чем делать транзакцию?
    • +1
      Во время отсчета может случиться, что одну купюру замяло, или она слиплась с другой, и банкомат отбраковывает всю пачку. Автоматически он не пытается набрать ее заново, а просто посылает на хост аппаратную ошибку о невозможности выдать указанную сумму. А там хост уже может сделать реверс или послать команду на выдачу во второй раз — но для этого ему нужно будет заново пересчитать покупюрную сумму. А она обычно считается во время выполнения транзакции и прикрепляется к ней, так что скорее всего будет реверс.

      Также банкомат может послать реверс сам сразу после сообщения о неудачной выдачи. Тут уж реверс придется делать.

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

      Другое дело, что если в банкомате физически нет запрошенной суммы на момент начала операции — тогда это косяк создателей сценария — могли бы сразу предупредить об этом.

      Может еще быть так, что физически сама сумма есть, но выдать ее имеющимися номиналами невозможно, причем, так как банкомат в большинстве случаев сам не рассчитывает покупюрный расклад, до того, как пошлется запрос на хост, это определить невозможно.
  • 0
    И еще интересно как некоторые банки умудряются отказывать в обслуживании по некоторым картам? Всегда снимал в Минске доллары в Приоре — давал по 400 за раз, в этом году — не дает и все. Нисколько. В любом их банкомате. Но белрубли — выдает нормально, а все другие банки с той же карты нормально выдают и доллары. И такое было еще раз в Смоленске — в какой-то момент Смоленский банк, земля ему пухом, тоже перестал выдавать доллары по этой карте. Прослеживается явная тенденция когда банки перестают любить какие-то определенные карты.
    • +2
      Может у этих банкоматов просто-напросто нет долларовых купюр?)
      • 0
        Вот не описал одну очевидную вещь и сразу версии посыпались. Есть конечно — прям за мной люди снимали.
    • 0
      Тут все зависит от наличия долларов в банкомате. И не все банкоматы настроены на выдачу долларов по всем картам. Так же от карты зависит и сумма за раз. Например в Приоре если использовать валютную карту Приора можно и 1000 за раз попросить, а если карта другого банка то максимум 200 (400 уже нигде не осталось). По иностранным картам он может даже не предложить выдачу валюты.
      • 0
        В том-то и дело что предлагает, пин спрашивает и потом опа — просто карту выплюнул. Причем это давно и много раз проверенные места…
  • 0
    И еще интересно )) кто зарабатывает на валютной конвертации? Только платежная система?
    • 0
      Банк обслуживающий банкомат устанавливает курсы. Вторая таблица
      • 0
        Сомнительное утверждение. По данной ссылке это инфа для клиентов банка, можешь свои доллары снять в рубли в родном же банкомате и не мучить кассира.
        Сколько раз снимал рубли или кроны — курс одинаковый в банкоматах всей страны, что наводит мысль на платежную систему. К тому же последнее время банки решили тоже на этом заработать и вылезти вперед, т.к. клиент общается с их железкой и банкоматы стали предлагать — а давай я с твоего счета спрошу не 10000 крон, а прям доллары. Вот только курс который предлагают они — вообще конский. Никогда не надо соглашаться! 3% — от платежной системы после этого кажутся манной небесной. Такое еще кстати стали практиковать в duty free при покупке. Тот же развод.
      • 0
        нет, банк-владелец банкомата даже не знает в какой валюте у Вас карта )
        Так что курсы устанавливать он тем более не может ))
  • +3
    На уровне «чайников» начинющих вкуривать тему нормально, разве что уточнить:

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

    п.3 На начальном этапе обработки карты ПО банкомата читает номер карты и по ее первым цифрам (это не обязательно BIN) может глобально переключится на ветку в сценарии работы и настроек. Т.е. если вы для примера знаете что для карт начинающихся с 445566 это японские карты то наверно японцам будет приятно увидеть иероглифы и не видеть дробную часть сумм.
    Соответственно если это служебные карты — то тут могут появится специальные служебные элементы для инкассаторов или технических специалистов.
    Но администраторы сценариев банкоматов очень ленивые FIT-таблицы практически не используются.

    п.4 В принципе да, но я бы разделил ПО для банкоматов по другому. Есть ПО которое:
    — обменивается с хостом по протоколам NDC/DDC
    — обменивается по самописному протоколу (для примера когда то так было в системе UnionCard)
    Первый вариант он более универсальный по типу подключения к процессингу, но ограниченный по визуальным возможностям и различным вкусностям в логику, и есть требования к кланам связи.
    Второй жестоко привязан к конкретному процессиингу, но реально может предъявлять смешные требования каналам связи. Реально возможно отправить в процессинг и принять из процессинга всего по 1-ой СМС. Вот и вся транзакция. Хотя в основе опять же лежит использования библиотек NDC/DDC но локально на банкомате.
    • +1
      п.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 на карте то становится сложно реализовывать механизм смны ПИН-кода.
        Т.е. примерно так.
        Тема не объятая, в одном посте не расскажешь.
        • 0
          Очень интересно было бы послушать описание механизмов безопасности с объяснением, почему сделано так; вот как вы сейчас рассказали. А то ведь мало знать механизмы, нужно понимать, зачем они были придуманы.

          Ну и принципиально процедуру проверки это не меняет. Кстати, хранятся у нас действительно PVV, о чем в названиях полей написано. Просто не знал таких тонкостей, поэтому рассказал так, чтобы понятно всем было.
        • +2
          длина пин-кода 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 по идее односторонняя. Хотя в ней есть свои криптографические скелеты.
  • 0
    Вот интересно, как можно использовать функцию «ПИН код наоборот, если ПИН код зеркальный? Например, 1221. Или же такие ПИН коды принципиально не формируются при выдаче карт?
    • 0
      Очевидно же! Просто в таком случае ложный ПИН работать не будет, потому что сначала идет проверка на то, что ПИН правильный, а потом на то, что он ложный.
      • 0
        Так я к тому и веду, то это выглядит существенной недоработкой данной системы. Сложно представить что данный момент не был продуман заранее.
  • 0
    Небольшое продолжение по возникшим вопросам — geektimes.ru/post/258978

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