7.6. ПОДТВЕРЖДЕНИЕ ПРОЦЕССА АУТЕНТИФИКАЦИИ
7.6. ПОДТВЕРЖДЕНИЕ ПРОЦЕССА АУТЕНТИФИКАЦИИ 
7.6.1. Инициация сессий аутентификации без участия конечного пользователя
В потоке аутентификации по отдельному каналу сервер авторизации должен иметь информацию о согласии конечного пользователя с процессом аутентификации. Для этого клиент должен передать идентификатор пользователя серверу авторизации. Если этот идентификатор в запросе аутентификации в качестве <login_hint> является статичным (например, номер телефона), то злоумышленник, выступающий в роли клиента, зная статичный идентификатор пользователя <login_hint>, может указывать его в запросах серверу авторизации и посылать такие запросы на AD пользователей. В качестве меры защиты необходимо дополнять запрос на аутентификацию пользователя некоторым идентификатором, служащим подтверждением согласия пользователя на аутентификацию. Такой идентификатор может быть получен одним из следующих способов:
1. <login_hint> с заявленным свойством <nonce>. Заявленное свойство <nonce> генерируется на устройстве AD, после чего попадает на сервер авторизации, с которым взаимодействует AD (например, фронт сервера авторизации), и затем этот <nonce> передается клиенту для включения в <login_hint>.
2. Одноразовый идентификатор конечного пользователя, перенесенный с AD на CD. Сервер авторизации может генерировать одноразовый идентификатор, который передается AD на CD в начале потока. При этом конечный пользователь аутентифицируется в AD и запрашивает идентификатор для потока в виде QR-кода, сканирует его на CD, после чего он передается с CD на клиента, где декодируется и используется для значения <login_hint_token> и проверяется сервером авторизации при инициировании потока аутентификации по отдельному каналу.
3. Одноразовый идентификатор конечного пользователя, перенесенный с CD на AD. Клиент может генерировать одноразовый идентификатор, который передается СD на АD в начале потока. При этом конечный пользователь аутентифицируется в AD и сканирует на AD сгенерированный CD идентификатор для потока в виде QR-кода, после чего он передается с AD на сервер авторизации. Декодированный идентификатор передается клиентом на сервер авторизации в качестве значения <login_hint_token> и проверяется сервером авторизации.
К одноразовым идентификаторам конечного пользователя должны применятся требования, аналогичные заявленному свойству <nonce>.
7.6.2. Подтверждение пользователем значения <binding_message>
В зависимости от информации о пользователе, используемой для его идентификации и процессов аутентификации пользователя клиентом, мошенник может осуществить запуск атаки подмены потока аутентификации, запустив собственный поток аутентификации на AD одновременно с подлинным потоком, причем оба потока будут использовать актуальный идентификатор пользователя. Если область запрашиваемого доступа аналогична, то, чтобы убедиться, что пользователь авторизует правильную транзакцию, необходимо, чтобы он сравнил значение <binding_message> на AD и CD или использовал альтернативные механизмы проверки <binding_message> (например, передавая его на устройство аутентификации через QR-код) либо временные идентификаторы пользователя, сгенерированные на AD (разделы 1, 2, пункт 7.6.1).
БИБЛИОГРАФИЯ
|
Название
|
Описание
|
|
[ГОСТ Р 34.10-2012]
|
Национальный стандарт Российской Федерации ГОСТ Р 34.10-2012 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи"
|
|
[Р 50.1.041-2002]
|
Рекомендации по стандартизации Р 50.1.041-2002 "Информационные технологии. Руководство по проектированию профилей среды открытой системы (СОС) организации-пользователя"
|
|
[ГОСТ Р 58833-2020]
|
Национальный стандарт Российской Федерации ГОСТ Р 58833-2020 "Защита информации. Идентификация и аутентификация. Общие положения"
|
|
[ГОСТ Р 57580.1-2017]
|
Национальный стандарт Российской Федерации ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер"
|
|
[ГОСТ Р 56939]
|
Национальный стандарт Российской Федерации ГОСТ Р 56939-2016 "Защита информации. Разработка безопасного программного обеспечения. Общие требования"
|
|
ФАПИ.СЕК
|
Стандарт Банка России СТО БР ФАПИ.СЕК-1.6-2020 "Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы обеспечения безопасности финансовых сервисов на основе протокола OpenID"
|
|
[ietf-oauth-mtls]
|
"OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC8705, февраль 2020
|
|
[OpenID. Core]
|
"OpenID Connect Core 1.0", ноябрь 2014
|
|
[OpenID. Discovery]
|
"OpenID Connect Discovery 1.0a", ноябрь 2014
|
|
[OpenID. DCR]
|
"OpenID Connect Dynamic Client Registration 1.0", ноябрь 2014
|
|
[OpenID.CIBA.Core]
|
OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-03, январь 2020
|
|
[OpenID.CIBA.RW]
|
Financial-grade API: Client Initiated Backchannel Authentication Profile, август 2019
|
|
[RFC6750]
|
"The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, октябрь 2012
|
|
[RFC7519]
|
"JSON Web Token (JWT)". RFC 7519, май 2015
|
|
[IANA. JWT]
|
IANA, "JSON Web Token (JWT)", март 2020
|
|
[IANA.OAuth.Parameters]
|
IANA, "OAuth Parameters", март 2020
|
|
[RFC6202]
|
"Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, апрель 2011
|
|
[RFC6749]
|
"The OAuth 2.0 Authorization Framework", RFC 6749, октябрь 2012
|
|
[RFC7231]
|
"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, июнь 2014
|
|
[RFC7521]
|
"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" RFC 7521, май 2015
|
|
[RFC7591]
|
"OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, июль 2015
|
|
[RFC8414]
|
"OAuth 2.0 Authorization Server Metadata", RFC 8414, июнь 2018
|
|
[RFC8628]
|
"OAuth 2.0 Device Authorization Grant", RFC 8628, август 2019
|
|
[RFC8705]
|
"OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC8705, февраль 2020
|
|
[RFC4648]
|
"The Base16, Base32, andBase64 Data Encodings", RFC4648, октябрь 2006
|
|
[N 152-ФЗ]
|
|
|
[N 1119]
|
Постановление Правительства Российской Федерации от 01.11.2012 N 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных"
|
|
[N 378]
|
Приказ ФСБ России от 10.07.2014 N 378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности"
|
|
[N 21]
|
Приказ ФСТЭК России от 18.02.2013 N 21 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных"
|
|
[N 382-П]
|
Положение Банка России от 09.06.2012 N 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств"
|
|
[N 683-П]
|
Положение Банка России от 17.04.2019 N 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента"
|
|
[N 757-П]
|
Положение Банка России от 20.04.2021 N 757-П "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций"
|
