Маскированный номер карты что это
Маскирование ИЛИ усечение номера PAN: в чем разница?
Я, конечно, не получаю пачками вопросы по безопасности платежных карт, однако, время от времени кто-нибудь да и задаст мне такой вопрос, который заслуживает отдельной публикации в блоге. Буквально на днях одна читательница, Мишель, задала мне такой вопрос, который, в целом отражает часто встречающееся непонимание в сфере безопасности платежных карт:
Вчера я перечитывала PCI DSS 2.0, требование 3.4, и была немало удивлена тем, что для защиты хранимых номеров PAN не предлагается такая мера как «маскирование». Правильно ли я понимаю, что эти номера подлежат шифрованию перед помещением их на хранение, а при извлечении, они подлежат расшифрованию и маскированию? И потом, если мы получаем номер PAN уже в маскированном виде, а затем храним его, то попадает ли такое хранение под действие стандарта PCI DSS? С технической точки зрения, как я думаю, не попадает, т.к. PAN уже маскирован при получении, а значит нет возможности найти номер PAN в незашифрованном виде.
Вот в этом как раз и кроется основная суть непонимания сути маскирования. Многие люди либо вообще не знают о существовании усечения и полагают, что если они не могут видеть полный номер карты, то это маскирование, либо считают, что усечение и маскирование — это одно и то же. Несомненно это разные вещи, поэтому я позволю себе процитировать определения маскирования и усечения прямо из Глоссария PCI SSC:
Маскирование (Masking)
Метод сокрытия сегмента данных при отображении или печати. Маскирование используется, когда нет служебной необходимости в просмотре всего номера PAN.
Усечение (truncation)
Метод приведения номера PAN к нечитаемому виду посредством удаления сегмента данных PAN.
Представьте себе данные о держателе карты (далее – ДДК) в виде цифр на листке бумаги. При маскировании мы словно берем коррекционную ленту и наносим ее на большую часть цифр таким образом, чтобы человеку, которому передается этот листок, было видно только последние 4 цифры. Очевидно, что при этой операции данные по прежнему существуют под коррекционной лентой, хотя она их и скрывает. Разумеется, с этого листка бумаги, приложив некоторые усилия, можно счистить коррекционную ленту, а значит этот лист бумаги по прежнему нуждается в защите, при которой никакие злоумышленники не могли бы восстановить и использовать данные о держателе карты.
В свою очередь, если бы мы хотели выполнить усечение на этом листке бумаги, то мы бы либо вообще изначально не писали эти цифры, либо стерли их настолько надежно, что их никогда нельзя было бы воссоздать. Такие данные никогда не были бы написаны на листе бумаги, а значит никак не могли бы быть использованы для мошенничества с платежными картами. В таком сценарии, этот лист бумаги не имеет никакой ценности для злоумышленника, а значит нет необходимости его защищать, по крайней мере в той же степени, в которой следует защищать маскированные данные. Конечно, к этим усеченным данным могут быть привязаны какие-то дополнительные данные или значения, но сами по себе усеченные данные ценности не имеют.
Если на экране отображаются данные, из которых видна только малая часть, то нельзя знать наверняка, какие именно представлены данные — усеченные или маскированные. Для того, чтобы это узнать, необходимо глубже понимать процессы их обработки. Только понимая процессы, можно сказать, можно ли каким-либо воссоздать эти данные или же в базе данных хранятся те же данные, которые видны на экране. Находясь в обычном магазине, можно увидеть на чеках последние 4 цифры номера карты. Если платежное приложение написано корректно, то должность персонала – будь то руководитель торгового зала или продавец — не должна иметь значения: в любом случае никто не должен видеть ничего кроме последних 4 цифр номера. Дело в том, что в таком приложении данные не сохраняются, а значит ни у кого из сотрудников магазина нет возможности извлечь данные из системы — данные усечены и их в системе больше нет.
Совсем иная ситуация в бэк-офисе, в бухгалтерии и в службе, отвечающей за предотвращение ущерба. По умолчанию, сотрудники этих отделов и служб должны видеть только 4 последних цифры номера платежной карты. Однако при возникновении претензионных платежей или подозрений на вероятное мошенничество, сотрудники компании в рамках расследования должны иметь возможность отменить маскирование полного номера карты. Эти номера по-прежнему существуют на сервере, однако, они там в основном хранятся в маскированном (скрытом) виде, и отображаются только должным образом уполномоченному персоналу. Поскольку имеется возможность извлечения этих данных на серверах, они полностью входят в область оценки на соответствие стандарту PCI DSS и подлежат соответствующей защите.
Таким образом, отвечая на вопрос читательницы, я скажу, что хранимые данные не могут быть «маскированы». Они маскируются только при извлечении и считаются маскированными, если отображены частично. Именно поэтому, в требовании 3.4 отсутствует маскирование. Если же ТСП получает ДДК, в которых имеется только сегмент номера PAN (например, сегмент из первых 6 или последних 4 цифр), то такие данные являются усеченными. В таком случае полный номер PAN отсутствует, воссоздание его невозможно, а значит нет необходимости его защищать так же, как и ДДК. Я не говорю, конечно, о том, что данные, привязанные к этому номеру не имеют ценности и не подлежат защите, просто усеченные данные не входят в область применения требований стандарта.
Если же ТСП получает полный номер PAN, но сотрудникам он отображается в маскированном виде, то, даже если никто в ТСП не имеет доступа к ДДК, оно все равно отвечает за их защиту согласно требованиям стандарта. Если в этих данных нет необходимости, есть смысл просить о предоставлении усеченных данных, тем самым, сэкономив кучу сил и нервов на общении с аудиторами, выполнении требований стандарта, да и вообще на процессе приведения среды в соответствие со стандартом PCI DSS. Например, я приятный в общении человек, но даже самые большие мои поклонники среди клиентов подтвердят, что я становлюсь противным и невыносимым, как минимум, раз в год, когда прихожу к ним для проведения аудита.
PCI DSS
Соответствие требованиям
Основное требование стандарта — максимально ограничить доступ к данным платежных карт. Оптимальным решением является вообще не иметь к ним доступа, а вместо этого использовать сертифицированных провайдеров для приема платежей. На практике это означает, что нельзя ни запрашивать, ни передавать номера карт. Если звонит клиент, говорит, что не проходит платеж и начинает диктовать номер, нужно его перебивать. Если присылает по почте/скайпу — удалять сообщение и просить, чтоб больше так не делал.
К охраняемым данным относятся полный номер карты и код CVV2/CVC2 (последние 3 цифры на обратной стороне). Имя владельца, срок действия и маскированный номер карты (первые 6 и последние 4 цифры) в защите по требованиям стандарта не нуждаются поэтому их можно использовать в разумных пределах.
Соответствие PCI DSS вместе с CloudPayments
CloudPayments — сертифицированный сервис-провайдер с максимальным уровнем соответствия PCI DSS, предоставляющим право хранить данные платежных карт и обрабатывать более 6 миллионов платежей ежегодно. Подтверждение соответствия проходит каждый год в рамках сертификационного аудита.
Все платежные инструменты CloudPayments спроектированы таким образом, что при их использовании вы автоматически соответствуете требованиям по безопасности. Дополнительных мер предпринимать не нужно.
Исключением является прием платежей по технологии Checkout. Для использования необходимо подтверждать соответствие: заполнить лист самооценки и ежеквартально проверять сайт на уязвимости специальным сканером.
Технология Checkout
Checkout — уникальная технология токенизации карт для приема платежей на вашем сайте, в вашей форме без встроенных iframe элементов, что дает максимальный контроль и конверсию прохождения платежей. Данные платежных карт шифруются в браузере покупателя, поэтому ваш сайт не принимает участие в обработке и хранении номеров, что значительно сокращает область применения требований PCI DSS. Тем не менее, сайт влияет на безопасность карточных данных, и для его защиты необходимо выполнять сканирование не менее одного раза в квартал для поиска вирусов и уязвимостей. Сканирование должно проводится аккредитованным вендором (ASV) из списка, представленного на сайте совета PCI.
Для поддержки качества и безопасности услуг, в компании работают 30 человек: есть отделы разработки, тестирования, эксплуатации и поддержки. Все сотрудники регулярно проходят обучение, имеют большой опыт работы с банковскими и процессинговыми системами, являются экспертами в области технологий и безопасности.
ASV-сканирование
ASV-сканирование — автоматизированная проверка вашего сайта на наличие уязвимостей. Сканер проверяет наличие вирусов, известных уязвимостей, таких как XSS, SQL Injections и так далее, после чего составляет детальный отчет с инструкцией по устранению проблем, если они были обнаружены.
Использование сканера необходимо для приема платежей по технологии Checkout, для остальных инструментов: виджет, мобильный SDK, рекарринг и рекуррент его использование не требуется.
Выбор вендора для сканирования остается на ваше усмотрение, но он должен быть из списка на сайте совета PCI. Если у вас нет предпочтений, мы рекомендуем использовать Trustwave — международную компанию, признанного лидера в информационной безопасности.
Инструкция для подключения ASV-сканера Trustwave
Годовая стоимость пакета услуг составляет 499 долларов и включает в себя подписку на сканирование, помощь в заполнении листа самооценки, учебные материалы и политику безопасности.
Зачем в пречеке скрывают цифры номера карты?
Когда я пополняю свою карту по ее номеру в каком-нибудь салоне связи, мне дают пречек на проверку. Номер карты в нем частично скрыт. Зачем скрывают цифры в середине номера карты? Как я могу их проверить, если сотрудник салона мне их не диктует, ссылаясь на требования безопасности?
Буду рад, если объясните, зачем это нужно, ведь просто по номеру карты списать деньги невозможно.
Павел, действительно, номер карты скрывают в целях безопасности. Чтобы ответить на ваш вопрос, нужно объяснить, из чего состоит номер карты.
Из чего состоит номер карты
Последняя цифра — специальная, рассчитывается по алгоритму «Луна». Это особая формула, которая формируется из остальных цифр карты и выступает проверкой правильности и подлинности карты.
Вы могли обратить внимание, что даже в личном кабинете номер карты полностью не указан. В Тинькофф-банке это выглядит так:
Почему не указывают данные карты
Полностью данные чеков и пречеков не указываются в связи с требованиями стандартов безопасности данных индустрии платежных карт. В них прописано, что в чеке максимально могут быть указаны первые 6 и последние 4 цифры карты.
Раньше у Тинькофф-банка была договоренность с партнерами, через которых можно было пополнять счет так, чтобы на пречеке номер карты указывался полностью. Но в связи с обращениями клиентов и принятыми стандартами теперь в пречеках стали указывать только последние 4 цифры номера карты.
Сотрудники салона чаще всего сами предлагают устно проверить номер введенной карты. Если вы переживаете, что могли ошибиться в номере карты, попросите сотрудника сверить с вами номер карты или пополняйте карту по номеру договора.
Если у вас есть вопрос о личных финансах, правах и законах, здоровье или образовании, пишите. На самые интересные вопросы ответят эксперты журнала.
Зачем заклеивают номер на обратной стороне банковской карты
В интернете часто можно встретить советы о том, как обезопасить себя от мошенничества с банковскими картами. Среди прочих можно встретить и рекомендации заклеить или замазать трехзначное число на обратной стороне карты.
Это число называется CVC2- или CVV2-код (Card Verification Code или Value). MasterCard использует название CVC, а Visa — CVV. В обоих случаях код выполняет одинаковую функцию: подтверждение онлайн-платежа. То есть в теории, зная реквизиты карты, любой человек сможет сделать с нее платеж.
Несмотря на то что код располагается на обратной стороне карты, его легко увидеть и запомнить. Когда вы расплачиваетесь в кафе или в любом другом месте, где ваша карта может попасть в руки к третьим лицам, вы всегда рискуете. Ничто не мешает недобросовестному работнику незаметно сфотографировать или переписать данные карты, а затем попробовать расплатиться ею в интернете.
Загвоздка кроется в том, что не для всех операций нужно вводить код подтверждения из SMS или мобильного приложения. Некоторые сервисы не требуют дополнительной проверки. Этим, естественно, пользуются мошенники. Например, при помощи сервисов бронирования отелей или доставки еды.
Поэтому некоторые держатели карт предпочитают скрыть код на обороте. Можно с уверенностью сказать, что вреда от этого точно не будет. Только все же не стоит сцарапывать код или замазывать его маркером. Лучше закрыть его так, чтобы не повредить карту. Например, можно заклеить ее тонким непрозрачным скотчем, зарисовать смывающимся маркером или корректором.
Для того чтобы минимизировать риски с платежными картами, лучше пользоваться бесконтактной оплатой. Например, Google Pay, Samsung Pay и Apple Pay принимают уже почти везде, где есть терминалы для приема платежей. Так как карту вы физически не предъявляете, то никто не увидит ее реквизиты.
Также опасность есть при оплате на сомнительных интернет-ресурсах или сайтах-клонах. Если вы ввели данные карты на таком сайте, то ими вполне могут воспользоваться повторно, списав со счета определенную сумму. Для таких платежей проще всего выделить отдельную карту и не держать на ней деньги, либо установить расходный лимит в приложении. Кроме того, в этом случае на основной карте также стоит запретить операции в интернете.
Еще один вариант — использовать платежную систему типа PayPal. Если продавец работает с этой системой, то вам не нужно вводить данные карты. Вы просто авторизируетесь в PayPal и платите с привязанной карты. К сожалению, в России сервис используется не так часто, но в зарубежных интернет-магазинах это один из самых удобных способов оплаты. Для оплаты по России можно использовать другие платежные системы, например QIWI.
Как замаскировать номер кредитной карты с помощью регулярного выражения?
Имеется тело POST-запроса:
Для записи в лог требуется привести его к виду
Это можно сделать следующим образом:
Но, поскольку использование модификатора eval является дурным тоном и в PHP 5.5 отмечено устаревшим, я переделал регулярное выражение с использованием preg_replace_callback:
Однако хотелось бы получить идеальный вариант с использованием чистого regexp.
Возможно ли это? Потребуется ли рекурсия?
Оценить 2 комментария
Вот оно! Всё-таки это возможно!
Огромное спасибо!
Окончательный вариант, чтобы избежать появления лишнего X:
Можно в том же выражении замаскировать CVV:
Решение для маскирования нескольких параметров:
Вы работаете в сертифицированной по PCI конторе?
Если нет, то вы не имеете права запрашивать CVV\CVC и номер карты. Хранить карту можно в формате «Первые шесть+последние четыре», это разрешено для передачи в открытом виде.
Раз уж так пошло, зачем вам вообще знать длину номера карты? Замените просто на «HIDDEN»
Да, мы сертифицированы.
Насчет зачем знать длину номера — ни за чем, просто хочется иметь логи в таком формате 🙂
Скорее всего, вы правы, стоит заменить иксы на такие константы.
В любом случае вы потенциально раскрываете информацию такой записью — потенциальный вредитель знает что карта 12 знаков, цивик — 4 у данного конкретного тела. Не шибко поможет, но в свете редковстречающихся 12знаков и 4знаков, вполне может хватить для чего-то неприличного.
Опять же, если вы хотите идентифицировать как-то карту, возможно использовать f(cc_number+cvc) где f например baseconvert(md5(data),10,26)