Оплата покупок при использовании банковской карты – авторизация и обмен информацией. Аутентификация держателя карты завершена неуспешно

Платежи по банковской карте – как происходит авторизация

Что происходит при установке банковской карты в считыватель терминала? Какая информация о платеже поступает в банк? Авторизация бесконтактных платежей происходит таким же образом, что и транзакций с использованием PIN-кода или подписи? Поговорим об этом подробнее.

Все мы знаем, что использование банковской картой – это быстрый и удобный способ оплаты покупок. Вся сделка сводится осуществляется за пару простых действий: мы должны ввести пластик в считыватель терминала, подождать некоторое время, чтобы получить подтверждение из банка, ввести ПИН-код или поставить свою подпись на бланке, и забрать чек, вместе с доказательством оплаты картой.

Все эти действия длятся всего несколько секунд и требуют от нас минимум усилий. Ещё быстрее проходят бесконтактные платежи картой, так как в этом случае не нужно вводить ПИН-код, что дополнительно сокращает длительность операции.

Однако, стоит знать, что хотя вся операция кажется простой и несложной, в действительности, она включает несколько этапов, а в её процесс вовлечено множество субъектов.

В процессе авторизации банковской карты участвуют:

пользователь карты – то есть клиент банка, пользующийся кредитной или дебетовой картой;
эмитент – банк, который выпустил карту;
акцептант – продавец, принимающий оплату картами;
платежный агент – компания, занимающаяся обслуживанием и регулированием платежных операций, а также обеспечивающая инфраструктуру для приема карт, нередко роль платежного агента выполняет эмитент;
платежная система – финансовое учреждение, предоставляющее банкам лицензии на выпуск карт, сопровождение сделок и обеспечивающая систему авторизации и клиринга платежей. Это, например, MasterCard, Visa, МИР.

В чём заключается авторизация сделки

Для того, чтобы сделка с использованием карты была подтверждена, в очень короткие сроки должны быть предоставлены следующие данные:

продавец (акцептант) должен убедиться, что карта действительна и активна, а человек, который её предоставил, имеет на это право;
платежный агент и платежная система должны получить от банка подтверждение, что на счету владельца карты находятся денежные средства, позволяющие покрыть сделку (соответствующие сальдо на счете или неиспользованный лимит овердрафта).

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

Процесс авторизации с подтверждением PIN-кодом или подписью

Многоэтапная процедура авторизации начинается с момента вставления карты с чипом в считыватель терминала (или протаскивания карты с магнитной полосой через считыватель). В этот момент устройство получает информацию о номере карты и периоде её действия, благодаря чему «знает», что карта активна.

Затем терминал передает эти данные платежному агенту и печатает первую часть квитанции (называемую в обиходе слип чек). На этой квитации, обычно, указывается адрес торговой точки и обязательно: клиентский номер магазина и номер карты.
Платежный агент осуществляет прием данных и через соответствующую компьютерную сеть отправляет их в платежную организацию (экспорт данных сопоставим с вопросом, возможно ли по указанному счету осуществить сделку на такую-то сумму). Каждая платежная система имеет свою собственную отдельную сеть IT-решений, например, для карт VISA – Visanet, а для карт MasterCard – Banknet.
Следующим этапом является окончательная авторизация транзакции. Эмитент карты (банк), после получения запроса от платежной организации, сравнивает запрашиваемую сумму с состоянием средств на счете клиента или с доступным кредитным лимитом.
Если стоимость сделки не превышает свободных средств клиента, банк отправляет код авторизации для платежной организации и, в то же время, блокирует сумму равную стоимости проведенной сделки, находящуюся на счете клиента.
Стоит добавить, что на данном этапе банк не взимает сумму сделки, а только блокирует её на счете – это означает, что средства по-прежнему находятся на нашем счете, но Вы не можете их использовать. Уменьшение остатка на величину платежа происходит только в момент подтверждения сделки.
На следующем этапе происходит передача информации в обратном порядке: банк направляет информацию в платежную организацию, которая передает её платежному агенту, а тот передает её на терминал в торговой точке. В это же время происходит окончательное подтверждение сделки со стороны держателя банковской карты – для того, чтобы сделка была успешно завершена, клиент должен ввести ПИН-код своей карты. Если PIN-код введен правильно, терминал печатает вторую часть квитанции.

Немного по-другому проходит завершение сделки, подтверждаемой подписью. В этом случае доказательство оплаты печатается сразу же после получения согласия на авторизацию через терминал. Клиент должен оставить на чеке свою подпись, а продавец сверить её с подписью на обратной стороне карты, а затем подтвердить транзакцию.

Авторизация транзакций в автономном режиме

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

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

Плюсы и минусы оффлайн авторизации

Оффлайн оплата удобны как для пользователя карты, как и для продавца в магазине. Акцептант не несёт расходов на связь с авторизующим центром, а заключение сделки занимает гораздо меньше времени, чем онлайн-сделка, во время которой банк проверяет состояние средств на счету пользователя.

К сожалению, подтверждение операций в автономном режиме предполагает определенный риск – поскольку на момент покупки информация об оплате не доходит до банка-эмитента карты, опрометчивые клиенты могут потратить больше, чем фактически есть на счете и, как следствие, попасть в несанкционированный овердрафт.

Блокировка авторизации банком или продавцом

Чаще всего, с отказом в авторизации мы можем встретиться в случае сделки, подтверждаемой PIN-кодом или подписью. Субъектом, который имеет тогда право отменить платеж, является банк или акцептант карты (продавец).

Блокировка операций через банк, чаще всего, имеет место в двух ситуациях:

когда пользователь карты не имеет достаточных средств на счете;
когда система авторизации банка посчитает этот платеж несанкционированным. В этом случае продавец, после появления соответствующего изображения на дисплее, обязан отменить платеж и аннулировать карту.

Стоит иметь в виду, что такое событие – хотя неприятное для клиентов – продиктовано соображениями безопасности. Системы авторизации банков имеют встроенные функции безопасности, позволяющие обнаружить подозрительные операции.

Например, если мы по нашей карте неожиданно запрашивается подтверждение оплаты в ювелирном магазине в Пекине или в течение нескольких дней подряд мы покупаем телевизоры, банк может посчитать, что наша карта попала в чужие руки и используется ворами.

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

Обязанность авторизации платежей также касается продавцов. Акцептант перед каждой сделкой банковской картой (за исключением бесконтактных) должен проверить, что карта имеет все характерные элементы, свидетельствующие об её подлинности.

В случае обнаружения таких нарушений, как:

повреждение карты;
изменения на панели для подписи;
изменения номера карты;
номер на печати с терминала, не соответствует номеру карты;
истёк срок действия карты.

Должен обязательно приостановить сделку и связаться с платежным агентом. Кроме того, имеет право попросить клиента предъявить документ, удостоверяющий его личность.

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

Если сделка не проверяется с помощью PIN-кода, продавец должен также проверить, соответствует ли подпись образцу подписи на карте (не касается проксимити-карт) и сравнить номер карты с номером, который частично или полностью напечатан на чеке.

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

Комментарий редакции

Авторизация кредитных карт – это сложный логистический процесс, в котором принимает участие несколько субъектов, а идентификации подлежит владелец карты, сама карта, а также средства на покрытие сделки (остаток на счете).

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

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

sberfan.ru

Аутентификация в автоматизированной банковской системе — Bankir.Ru

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

Для примера рассмотрим автоматизированную банковскую систему (АБС), с помошью которой клиент банка управляет своими банковскими счетами, например, переводит деньги со счет на счет, оплачивает услуги и платит в интернет-магазинах. Итак, Иванов хочет оплатить коммунальные услуги с использованием АБС. Для этого Иванову необходимо «представиться» АБС — указать некоторые проверочные данные (подтверждающие, что с АБС работает именно Иванов), то есть пройти аутентификацию. Далее ИПС проверяет, с какими счетами, и какие операции может выполнять Иванов, то есть выполняется процесс авторизации.

Чаще всего при аутентификации используется логин и пароль. Такой метод аутентификация называется однофакторным, так как базируется на одном факторе — статической информации (логине), которую мы знаем и предоставляем системе в процессе аутентификации.

Чем плоха однофакторная аутентификации, или фишинг и фарминг.

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

Итак, методы изъятия данных аутентификации: фишинг и фарминг.

Первый термин (phishing) происходит от английских слов password и fishing — пароль и ловля рыбы. Суть обеих атак заключается в том, что пользователь вводит свои данные аутентификации не на web-странице АБС, а на «фальшивой», визуально полностью похожей на нее. С фальшивой страницы данные попадают к злоумышленникам, что позволяет им пройти аутентификацию в АБС от имени пользователя со всеми вытекающими последствиями — обнуление счета.

Разница между этими атаками заключается только в способе «попадания» пользователя на фальшивую страницу.

В первом случае используется спам-рассылка «от имени» АБС, в которой пользователю «под разным соусом» предлагают посетить АБС, указывая при этом адрес фальшивой страницы. Предлогов масса: необходимость перерегистрироваться, заполнить бонусную анкету, получить подарок в честь столетия АБС и т.д.

Второй тип атак похож на описанный выше и предполагает переадресацию на хакерский web-сайт, что становится возможным за счет уязвимостей браузеров, операционных систем или DNS-атак. Кроме того, не стоит забывать о троянском программном обеспечении, которое успешно «ворует» данные.

Стоит отметить, что все АБС содержат информационные разделы, описывающие правила безопасного выполнения финансовых интернет-операций, как-то: ручной ввод URL АБС, работа только по защищенному протоколу, проверка SSL-сертификата, использование антивирусов и т.д. Кроме того, практически во всех случаях дополнительно указывается, что данная платежная система никогда не рассылает письма с предложением посетить АБС, и все рассылки, если таковые имеют место быть, персонализированы.

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

Методы предотвращения фишинга и фарминга.

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

Существует два метода борьбы с этими атаками.

Первый метод: необходимо удостовериться, что ввод данных осуществляется именно на «настоящей» странице. Для этого предполагается использование взаимной аутентификации, то есть с одной стороны пользователь подтверждает свою личность, но при этом и web-ресурс некоторым образом подтверждает пользователю свою идентичность.

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

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

Существует несколько широко известных методов аутентификации, стойких к рассматриваемым атакам. Вот перечень наиболее известных из них, они базируются на использовании

• Аппаратных генераторов одноразовых паролей (OTP, one-time password)

• Подписи транзакций на базе OTP (с использованием аппаратного генератора)

• Одноразовых паролей, генерируемых банковской пластиковой EMV-картой (MsaterCard EMV CAP, Visa EMV DPA)

• Одноразового пароля, высылаемого по SMS

• Цифровых сертификатов (с использованием смарт-карт, секретный ключ неизвлекаемый)

• Списка одноразовых паролей

• Табличного метода

• Секретных вопросов

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

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

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

Предлагаю рассмотреть две системы аутентификации, которые реализуют множество методов аутентификации на базе динамических данных.

Entrust IdentityGuard.

Оптимально решение для систем электронных платежей.

Основой Entrust IdentityGuard является Entrust IdentityGuard Server, который, собственно, выполняет аутентификацию пользователей, управление данными пользователя и их данными аутентификации.

Реализуемые методы аутентификации с использованием:

• Генераторов одноразовых паролей (OTP, one-time password)

• Подписи транзакций на базе OTP в режиме запрос-ответ

• Одноразового пароля, высылаемого по SMS

• Табличного метода

• Списка одноразовых паролей (как вырожденный табличный метод)

• Секретных вопросов

• Аутентификация компьютера

Рассмотрим более подробно наиболее интересные методы.

Генерируемые одноразовые пароли.

В основе этого метода лежит использование аппаратного генератора одноразовых паролей. При желании можно ввести дополнительный уровень защиты в виде использования статического PIN.

Статический PIN является дополнением к коду динамическому и защищает от использования генератора в случае кражи/потери.

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

Табличная аутентификация.

Интересный и экономически выгодный метод, реализующий, в том числе, и взаимную аутентификацию.

Суть метода. Пользователь имеет таблицу (или сетку, так как в оригинале метод называется grid — сетка). Каждая ячейка содержит некоторое количество символов. Значения указанных системой ячеек являются информацией, используемой для аутентификации (секретом).

Процесс аутентификации:

• Entrust IdentityGuard генерирует запрос (номера ячеек, значения которых необходимо указать)

• Пользователь вводит требуемые значения.

• Entrust IdentityGuard проверяет введенные значения.

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

Структура таблицы может быть сконфигурирована персонально для каждой групп пользователей. Метод формирования запроса и срок использования карты также настраивается.

Entrust IdentityGuard поддерживает разные варианты выпуска таблиц. Поддерживается конвейерный способ генераций, который подразумевает предварительную генерацию таблиц с последующей привязкой к пользователю. Стоит отметить, что стоимость выпуска и доставки карты пользователю может быть фактически сведена к нулю, так как таблица может быть отпечатана просто на бумаге или вообще отправлена по электронной почте в виде графического файла.

Список паролей.

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

Высылаемый PIN.

Эта концепция предполагает генерацию одноразового пароля Entrust IdentityGuard по запросу пользователя, например, автоматически при прохождении первого этапа аутентификации.

Сгенерированный PIN отправляется пользователю, например, в виде SMS, электронного письма и звонка на зарегистрированный номер.

ActivIdentity 4TRESS Authentication Server

Оптимальное решение для банков, предоставляющих услуги АБС.

Так как деление областей применения на банки, предоставляющие услуги АБС, и платежные системы весьма условно, и с точки зрения аутентификации мало чем отличается, поясним, что именно делает это решение привлекательным именно для банков.

В первую очередь — это возможность реализации многоканальности. Вполне понятно, что аутентификация пользователя может происходить не только при использовании АБС, но и, например, при обращении в центр телефонного обслуживания: в этом случае оператор также должен удостовериться в том, что звонящий является тем, за кого себя выдает. Кроме того, на базе ActivIdentity 4TRESS Authentication Server возможно построение модели внутрикорпоративной аутентификации, то есть сотрудников — операторов, операционистов, клерков в корпоративных системах.

Второй момент — это перечень реализуемых методов аутентификации:

• Генераторы одноразовых паролей (OTP, one-time password)

• Подпись транзакций на базе OTP в режиме запрос-ответ

• Одноразовые паролей, генерируемые банковской пластиковой EMV-картой (MsaterCard EMV CAP, Visa EMV DPA)

• Подпись транзакций на базе банковской пластиковой EMV-карты (MasterCard EMV CAP, Visa EMV DPA)

• Цифровых сертификатов (с использованием смарт-карт)

• Секретных вопросов.

ActivIdentity 4TRESS Authentication Server основан на сервис-ориентированной архитектуре (SOA, Service Oriented Architecture), что позволяет при необходимости подключить к системе любой другой метод аутентификации, не внося изменений в уже существующую информационную структуру. Это особо интересно в случаях, когда АБС уже использует какие-либо методы, и стоит задача перехода на более надежные модели. В этом случае существующие системы интегрируются в 4TRESS AS как подсистемы, что позволяет выполнить плавную миграцию.

В контексте банковского применения особо стоит отметить метод, использующий EMV-карты. Чипованные карты (EuroCard, MssterCard, Visa), выпускаемые банками для платежей в магазинах, снятия денег в банкоматах, а также выполнения интернет-платежей, полностью готовы для генерации одноразовых паролей и подписи транзакций. Для этого пользователю необходимо всего лишь иметь устройство — Solo Reader, которое не требует подключения к компьютеру. Со стороны банка проверку OTP и подписи транзакции выполняет рассматриваемый здесь ActivIdentity 4TRESS Authentication Server (сертифицирован платежными системами MasterCrad и Visa, а также EMV).

Этот метод аутентификации интересен еще и тем, что карта, как говорилось, уже готова для генерации OTP, то есть регистрация и выпуск аутентификация в АБС выполняется практически автоматически.

Еще один вариант аутентификации на базе одноразовых паролей — это использование DisplayCard. Обычной банковской карты, в которую встроен генератор одноразовых паролей. Такая концепция очень привлекательная для конечного пользователя, так как не требует для аутентификации в АБС вообще ничего, кроме пластиковой карточки, которая уже используется для снятия денег в банкомате и платежей в магазинах.

Собственно, что получаем в качестве сухого остатка?

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

bankir.ru

SMS аутентификация в Сбербанк Бизнес ОнЛайн

После завершения авторизации в системе пользователю может быть предложено выполнить процедуру SMS-аутентификации, являющейся дополнительным методом уменьшить риски, связанные с компрометацией пароля пользователя при работе через сеть интернет.

Сообщение, содержащее данные для прохождения SMS-аутентификации отправляется на мобильный телефон пользователя системы в виде SMS-сообщения (см. Рисунок).

Пример SMS-сообщения при аутентификации в Сбербанк Бизнес ОнЛайн

Альтернативное средство подписи (АСП)

Для гарантии целостности документов, передаваемых пользователями в Сбербанк, и подтверждения их авторства в системе Сбербанк Бизнес ОнЛайн документы необходимо подписывать с помощью АСП (исключая документы типа«Заявка»).

Альтернативное средство подписи представляет собой механизм подтверждения операций одноразовым паролем, передаваемым банком на номер мобильного телефона уполномоченного представителя Клиента (пользователя) в виде SMS-сообщения в момент инициации процесса подписи документа.

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

Пример сообщения альтернативного средства подписи

business-and-banks.ru