Обзор способов и протоколов аутентификации в веб-приложениях
Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.
Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.
Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.
Однако в современных системах существуют и более сложные схемы аутентификации и авторизации, о которых я расскажу далее. Но начнем с простого и понятного.
Аутентификация по паролю
Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.
Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.
HTTP authentication
Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:
Весь процесс стандартизирован и хорошо поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:
Forms authentication
Для этого протокола нет определенного стандарта, поэтому все его реализации специфичны для конкретных систем, а точнее, для модулей аутентификации фреймворков разработки.
Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.
Пример forms authentication.
Приложение может создать session token двумя способами:
Другие протоколы аутентификации по паролю
Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.
Существует всего несколько мест, где можно передать username и password в HTTP запросах:
Распространенные уязвимости и ошибки реализации
Аутентификации по паролю считается не очень надежным способом, так как пароль часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей.
Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:
Аутентификация по сертификатам
Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.
На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.
В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.
Использование сертификата для аутентификации.
Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:
Пример X.509 сертификата.
После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).
Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation). Однако трудности с распространением и поддержкой сертификатов делает такой способ аутентификации малодоступным в широких кругах.
Аутентификация по одноразовым паролям
Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.
Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.
Существуют разные источники для создания одноразовых паролей. Наиболее популярные:
Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.
В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.
Аутентификация по ключам доступа
Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.
В большинстве случаев, сервер генерирует ключи доступа по запросу пользователей, которые далее сохраняют эти ключи в клиентских приложениях. При создании ключа также возможно ограничить срок действия и уровень доступа, который получит клиентское приложение при аутентификации с помощью этого ключа.
Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.
Пример применения аутентификации по ключу.
Использование ключей позволяет избежать передачи пароля пользователя сторонним приложениям (в примере выше пользователь сохранил в веб-приложении не свой пароль, а ключ доступа). Ключи обладают значительно большей энтропией по сравнению с паролями, поэтому их практически невозможно подобрать. Кроме того, если ключ был раскрыт, это не приводит к компрометации основной учетной записи пользователя — достаточно лишь аннулировать этот ключ и создать новый.
С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.
Пример аутентификации по ключу доступа, переданного в HTTP заголовке.
Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.
Аутентификация по токенам
Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.
Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:
Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.
Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.
Пример аутентификации «пассивного» клиента посредством перенаправления запросов.
Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.
Сам токен обычно представляет собой структуру данных, которая содержит информацию, кто сгенерировал токен, кто может быть получателем токена, срок действия, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.
При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:
В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.
Форматы токенов
Существует несколько распространенных форматов токенов для веб-приложений:
Пример SWT токена (после декодирования).
Issuer=http://auth.myservice.com&
Audience=http://myservice.com&
ExpiresOn=1435937883&
UserName=John Smith&
UserRole=Admin&
HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
Пример подписанного JWT токена (после декодирования 1 и 2 блоков).
Стандарт SAML
Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.
Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:
Кроме того, стандарт определяет формат обмена метаинформацией между участниками, которая включает список поддерживаемых ролей, протоколов, атрибутов, ключи шифрования и т. п.
Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:
В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):
После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).
Стандарты WS-Trust и WS-Federation
WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.
Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.
Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:
Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.
Стандарты OAuth и OpenID Connect
В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).
Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.
Чтобы лучше понять сам стандарт, рассмотрим пример веб-приложения, которое помогает пользователям планировать путешествия. Как часть функциональности оно умеет анализировать почту пользователей на наличие писем с подтверждениями бронирований и автоматически включать их в планируемый маршрут. Возникает вопрос, как это веб-приложение может безопасно получить доступ к почте пользователей, например, к Gmail?
> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.
Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:
Взаимодействие компонентов в стандарте OAuth.
Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:
Стандарт не определяет формат токена, который получает приложение: в сценариях, адресуемых стандартом, приложению нет необходимости анализировать токен, т. к. он лишь используется для получения доступа к ресурсам. Поэтому ни токен, ни грант сами по себе не могут быть использованы для аутентификации пользователя. Однако если приложению необходимо получить достоверную информацию о пользователе, существуют несколько способов это сделать:
Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.
Заключение
В этой статье мы рассмотрели различные методы аутентификации в веб-приложениях. Ниже — таблица, которая резюмирует описанные способы и протоколы:
Коды ошибок Visa/MasterCard/МИР
В данной статье собраны коды ошибок действующих банков-эквайеров.
Часто встречающиеся ошибки:
Код 05 – отказ эмитента без указания причины
Код 17 – отказать, отклонено пользователем карты
Код 41 – утерянная карта
Код 43 – украденная карта
Код 51 – недостаточно средств для проведения операции
Код 57 – недопустимый тип операции для данного типа карты (например, попытка оплаты в магазине по карте предназначенной только для снятия наличных)
Код 61 – превышение максимальной суммы операции или количества попыток для данной карты; превышен лимит на терминале продавца; недостаточно средств на счете продавца, в случае выплат (более точное описание смотрите ниже, исходя из обслуживающего банка)
Код 62 – заблокированная карта
Код 65 – превышение максимального количества операции для данной карты
Код 83 – ошибка сети (технические проблемы)
Код 91 – эмитент недоступен (технические проблемы на стороне банка-эмитента)
Код 96 – системная ошибка/невозможно связаться с банком, который выдал карту (требуется сверка с эквайером)
Полный список кодов ПАО « Промсвязьбанк » :
| Result Code | Description | Описание |
| 0 | Approved | Операция прошла успешно |
| 1 | Call your bank | Позвоните в свой банк |
| 3 | Invalid merchant | Недействительный продавец |
| 4 | Your card is restricted | Ограничение в проведении операции на стороне эмитента |
| 5 | Transaction declined | Операция отклонена без указания причины |
| 12 | Invalid transaction | Недействительная операция, возможно ошибки в параметрах запроса к платёжной системе |
| 13 | Invalid amount | Недопустимая сумма |
| 14 | No such card | Такая карта не существует |
| 15 | No such card/issuer | Нет такой карты / эмитента |
| 20 | Invalid response | Неверный ответ |
| 30 | Format error | Ошибка в параметрах запроса к платёжной системе |
| 41 | Lost card | Карта утеряна (статус установлен у эмитента) |
| 43 | Stolen card | Карта украдена |
| 51 | Not sufficient funds | Недостаточно средств |
| 54 | Expired card | Срок действия карты истёк |
| 55 | Incorrect PIN | Неверный PIN-код |
| 57 | Not permitted to client | Операция не разрешена для клиента (как правило, о тказ приходит со стороны платёжной системы) |
| 58 | Not permitted to merchant | Не разрешено продавцу (заблокирован терминал) |
| 61 | Exceeds amount limit | Сумма операции превысила допустимый лимит (также, возможен отказ от платёжной системы) |
| 62 | Restricted card | Запрещённая карта |
| 63 | Security violation | Нарушение безопасности |
| 65 | Exceeds frequency limit | Превышен лимит |
| 75 | PIN tries exceeded | Превышено количество попыток ввода PIN-кода |
| 76 | Wrong PIN,tries exceeded | Неверный PIN-код, количество попыток превышено |
| 82 | Time-out at issuer | Тайм-аут при соединении с эмитентом |
| 83 | Transaction failed | Транзакция неуспешна |
| 86 | Unable to verify PIN | Невозможно проверить PIN-код |
| 89 | Authentication failure | Ошибка аутентификации |
| 91 | Issuer unavailable | Эмитент недоступен |
| 93 | Violation of law | Операция отклонена. Держателю необходимо обратиться в свой банк |
| 95 | Reconcile error | Возникает, когда операция была уже проведена. |
| 96 | System malfunction | Системная ошибка \ Возможно ошибки в параметрах запроса к платёжной системе |
| -2 | Bad CGI request | Неверно сформирован запрос к платёжному шлюзу |
| -3 | No or Invalid response received | Платёжный шлюз вовремя не получил ответ. Статус операции при этом может быть успешным или неуспешным. |
| -4 | Server is not responding | Сервер не отвечает |
| -5 | Connect failed | Сбой соединения |
| -8 | Error in card number field | Ошибка в поле номера карты |
| -9 | Error in card expiration date field | Введена неверная дата срока действия карты |
| -10 | Error in amount field | Ошибка в поле суммы |
| -11 | Error in currency field | Ошибка в поле валюты |
| -12 | Error in merchant terminal field | Некорректный запрос к платежному шлюзу |
| -17 | Access denied | Отказано в доступе (Возможно ошибка при формировании P_SIGN) |
| -18 | Error in CVC2 or CVC2 Description fields | Ошибка в поле CVC2 |
| -19 | Authentication failed | Аутентификация прошла неуспешно (3d-secure), возможны другие причины. |
| -20 | Expired transaction | Время проведения операции превышает значение параметра TIMESTAMP |
| -21 | Duplicate transaction | Отправлен повторный запрос с идентичными параметрами |
| 70001 | Not sufficient funds | Недостаточно средств на счете. |
Полный список кодов ПАО Банк «ФК Открытие»:
| Result Code | Description | Описание |
| 00 | Approved | Успешная транзакция |
| 01 | Refer to card issuer | Обратитесь к эмитенту карты |
| 02 | Refer to card issuer, special condition | Обратитесь к эмитенту карты, особое условие |
| 03 | Invalid merchant or service provider | Недействительный идентификатор продавца |
| 04 | Pickup card | Изъять карту |
| 05 | Do not honor | Транзакция была отклонена эмитентом без объяснения причин |
| 06 | Error | Эмитент карты вернул ошибку без дополнительных объяснений |
| 07 | Pickup card, special condition (other than lost/stolen card) | Изъять карту, специальные условия |
| 08 | Honor with identification | Не пройдена идентификация, проблема с идентификацией |
| 09 | Request in progress | Выполняется запрос |
| 10 | Approved for partial amount | Одобрено для частичной суммы |
| 11 | Approved, VIP Approved, VIP program | Одобрено для VIP, программа VIP |
| 12 | Invalid transaction | Запрошенная транзакция не поддерживается или недействительна для представленного номера карты |
| 13 | Invalid amount | Сумма превышает лимиты, установленные эмитентом для данного типа транзакции |
| 14 | Invalid card (no such number) | Эмитент указывает, что эта карта недействительна. |
| 15 | No such issuer | Номер эмитента карты недействителен |
| 16 | Approved, update track 3 | Утверждено, обновить |
| 17 | Customer cancellation | Отмена клиентом |
| 18 | Customer dispute | Открыт спор с клиентом |
| 19 | Re-enter transaction | Клиент должен повторно отправить транзакцию |
| 20 | Invalid response | Неверный ответ |
| 21 | No action taken | Никаких действий не предпринимается. Эмитент отказался без других объяснений |
| 22 | Suspected malfunction | Предполагаемая неисправность |
| 23 | Unacceptable transaction fee | Неприемлемая комиссия за транзакцию |
| 24 | File update not supported | Обновление файла не поддерживается |
| 25 | Unable to locate record | Невозможно найти запись |
| 26 | Duplicate record | Дублирующая запись |
| 27 | File update edit error | Ошибка редактирования обновления файла |
| 28 | File update file locked | Файл/обновления файла заблокировано |
| 29 | not used | не используется |
| 30 | Format error | Ошибка формата |
| 31 | Bank not supported | Банк не поддерживается коммутатором |
| 32 | Completed partially | Завершено частично |
| 33 | Expired card, pick-up | Срок действия карты истек |
| 34 | Issuer suspects fraud, pick-up card | Эмитент карты подозревает мошенничество |
| 35 | Contact acquirer, pick-up | Обратиться к эмитенту карты |
| 36 | Restricted card, pick-up | Ограничено эмитентом карты |
| 37 | Call ECHO security, pick-up | Обратитесь в службу безопасности |
| 38 | PIN tries exceeded, pick-up | Количество попыток получения PIN-кода превышает лимиты эмитента |
| 39 | No credit account | Нет кредитного счета |
| 40 | Function not supported | Запрошенная функция не поддерживается |
| 41 | Pickup card (lost card) | Карта была утеряна |
| 42 | No universal account | Нет универсальной учетной записи |
| 43 | Pickup card (stolen card) | Карта была украдена |
| 44 | No investment account | Нет инвестиционного счета |
| 45 | 50 not used | не используется |
| 51 | Not sufficient funds | Недостаточно средств на карте |
| 52 | No checking account | Нет текущего счета |
| 53 | No savings account | Нет сберегательного счета |
| 54 | Expired card | Срок действия карты истек |
| 55 | Incorrect PIN | Неправильный PIN-код держателя карты |
| 56 | No card record | Нет такой карты |
| 57 | Transaction not permitted to cardholder | Операция не разрешена держателю карты. Карта не разрешена для запрошенного типа транзакции. |
| 58 | Transaction not permitted on terminal | Транзакция не разрешена на терминале. Продавцу запрещен этот тип транзакции (заблокирован терминал; сработало ограничение и т.д. необходимо уточнять подробности у эквайера) |
| 59 | Suspected fraud | Предполагаемое мошенничество |
| 60 | Contact ECHO | Связаться с службой безопасности |
| 61 | Exceeds withdrawal limit | |
| 62 | Restricted card | Карта заблокирована |
| 63 | Security violation | Нарушение безопасности. Карта заблокирована |
| 64 | Original amount incorrect | Неверная исходная сумма |
| 65 | Activity count limit exceeded | Превышено допустимое количество ежедневных транзакций |
| 66 | Call acquirer security | Связаться со службой безопасности эквайера |
| 67 | not used | не используется |
| 68 | Response received too late | Ответ получен слишком поздно |
| 69 | 74 not used | не используется |
| 75 | PIN tries exceeded | Превышено допустимое количество попыток ввода PIN-кода |
| 76 | Invalid «to» account | Неверный счет. Дебетового счета не существует |
| 77 | Invalid «from» account | Недействительный счет. Кредитный счет не существует |
| 78 | Invalid account specified (general) | Связанная учетная запись с номером карты недействительна или не существует |
| 79 | Already reversed | Уже отменено |
| 80 | Visa transactions: credit issuer unavailable | Операции с Visa: эмитент недоступен |
| 81 | PIN cryptographic error found | Обнаружена криптографическая ошибка PIN-кода |
| 82 | Negative CAM, dCVV, iCVV, or CVV results | Некорректный CAM, dCVV, iCVV или CVV |
| 83 | Unable to verify PIN | Невозможно проверить PIN-код |
| 84 | Invalid authorization life cycle | Просроченная авторизация |
| 85 | not used | не используется |
| 86 | Cannot verify PIN | Невозможно проверить PIN-код |
| 87 | Network Unavailable | Сеть недоступна |
| 88 | Invalid CVC2 | Ошибочно введенный cvc2 |
| 89 | Ineligible to receive financial position information | Невозможно получить финансовую информацию |
| 90 | Cut-off in progress | Отключение в процессе |
| 91 | Issuer or switch inoperative | Банк-эмитент недоступен |
| 92 | Routing error | Ошибка маршрутизации |
| 93 | Violation of law | Нарушение закона |
| 94 | Duplicate transaction | Дублирующая транзакция |
| 95 | Reconcile error | Ошибка согласования/ошибка при расчетах с МПС/НСПК |
| 96 | System malfunction | Произошла системная ошибка |
| 97 | not used | не используется |
| 98 | Exceeds cash limit | Превышен денежный лимит |
| -2 | Bad CGI request | Запрос не прошел CGI-проверку |
| -3 | No or Invalid response received | Хост эквайрера (NS) не отвечает |
| -4 | Server is not responding | Нет соединения с хостом эквайрера |
| -5 | Connect failed | Ошибка соединения с хостом эквайрера (NS) во время обработки транзакции |
| -6 | Configuration error | Ошибка настройки модуля e-Gateway |
| -7 | Incorrect response from the acquirer host | Некорректный ответа хоста эквайрера (NS), например, отсутствуют обязательные поля |
| -8 | Error in card number field | Ошибка в поле «Card number» запроса |
| -9 | Error in card expiration date field | Ошибка в поле «Card expiration date» запроса |
| -10 | Error in amount field | Ошибка в поле «Amount» запроса |
| -11 | Error in currency field | Ошибка в поле «Currency» запроса |
| -12 | Error in merchant terminal field | Ошибка в поле «Merchant ID» запроса |
| -13 | System error | IP-адрес источника транзакции (обычно IP торговца) не соответствует ожидаемому |
| -14 | No connection | Нет соединения с PIN-клавиатурой Интернет-терминала либо программа-агент на компьютере/рабочей станции Интернет-терминала не запущена |
| -15 | Error in the «RRN» field of the request | Ошибка в поле «RRN» запроса |
| -16 | Another transaction is in progress on the terminal | На терминале выполняется другая транзакция |
| -17 | The terminal is denied access to the e-Gateway module | Терминалу отказано в доступе к модулю e-Gateway |
| -18 | Error in the «CVC2» or «CVC2 Description» field of the request | Ошибка в поле «CVC2» или «CVC2 Description» запроса |
| -19 | Error in request for authentication information or authentication failed | Ошибка в запросе на аутентификационную информацию либо аутентификация неуспешна |
| -20 | Permissible time interval exceeded | Превышен допустимый временной интервал (по умолчанию – 1 час) между значением поля «Time Stamp» запроса и временем модуля e-Gateway |
| -21 | Transaction has already been completed | Транзакция уже выполнена |
| -22 | Transaction contains invalid authentication information | Транзакция содержит ошибочную аутентификационную информацию |
| -23 | Error in transaction context | Ошибка в контексте транзакции |
| -24 | Inconsistency in the context of a transaction | Несоответствие в контексте транзакции |
| -25 | Transaction aborted by user | Транзакция прервана пользователем |
| -26 | Invalid BIN of the card | Неверный BIN карты |
| -27 | Seller name error | Ошибка в имени продавца |
| -28 | Error in additional data | Ошибка в дополнительных данных |
| -29 | Error in authentication link (damaged or duplicated) | Ошибка в ссылке аутентификации (повреждена или дублируется) |
| -30 | Transaction was rejected as fraudulent | Транзакция отклонена как мошенническая |
| -31 | Transaction in progress | Транзакция в процессе выполнения |
| -32 | Re-declined transaction | Повторная отклоненная транзакция |
| -33 | client authentication in progress | Транзакция в процессе аутентификации клиента с помощью авторизации случайной суммы или одноразового случайного кода |
| -34 | MasterCard Installment транзакция в процессе выбора пользователем способа оплаты | |
| -35 | MasterCard Installment транзакция в процессе выбора пользователем способа оплаты была отклонена автоматически после превышения лимита времени на эту операцию | |
| -36 | MasterCard Installment транзакция в процессе выбора пользователем способа оплаты была отклонена самим пользователем |
