В последнее время сильное развитие получили веб-сервисы и мобильные приложения. На базе этого появилась возможность проведения различного рода операций, требующих аутентификацию. В частности, в банках появились такие сервисы, как мобильный банк, банк онлайн, банковское мобильное приложение. Банки предоставляют услуги проведения операций через использование таких сервисов.
Очевидно, что для проведения таких серьёзных операций необходимо идентифицировать пользователя. Процессу идентификации предшествует процесс аутентификации.
Также в аутентификации существуют такое понятие, как фактор аутентификации — различные отличительные черты субъекта, его характеристики. Сейчас использование той или иной характеристики в системе зависит от требуемой надёжности, защищённости и стоимости внедрения. Выделяют 3 фактора аутентификации:
- Я знаю;
- Я имею;
- Я есть.
В сленге банковских специалистов, и не только, за последние годы появилось такие выражение как «сильная» аутентификация, которая как раз и отражает удалённую аутентификацию клиента в таких сервисах. Это понятие не ограничивается банками: существует множество трактовок этого понятия, что взывает путаницу.
Определение проблемы
«Сильная» аутентификация — аутентификация, при которой пользователь отождествляется с реальным лицом, организацией или доверителем. Очень часто «сильную» аутентификацию отождествляют с двухфакторной аутентификацией, но это неверно. «Сильная» аутентификация не всегда может быть многофакторной: ответ на несколько вопросов также будет являться «сильной» аутентификацией.
Например, при звонке в банк в целях идентификации часто спрашивают номер карты, номер паспорта, место рождения и так далее. Всё это попадает под один фактор «я знаю» и значит не является многофакторной аутентификацией, но тем не менее является «сильной» аутентификацией. На практике в таких случаях рекомендуют применять многофакторную аутентификацию.
До недавнего времени не было ни одного официального документа, где определялось или фигурировало бы это понятие. Иногда это понятие используется в подтексте криптографии: аутентификация по протоколу «запрос-ответ-запрос-ответ» определяется там как «сильная», но это также не совсем верно. [1]
Определение ЕЦБ
31 января 2013 года Европейский Центральный Банк выпустил ряд обязательных рекомендаций к интернет-сервисам поставщиков платёжных услуг (Payment service provider), требующих соблюдение принципов «сильной (клиентской) аутентификации».
Это стал первый в мире нормативно правовой документ, где официально фигурирует и определяется это понятие. 1 февраля 2015 года на территории ЕС вошло в силу обязательное соблюдение данных рекомендаций.
Ниже представлена основная выжимка этих документов:
Рекомендации применяются к таким процедурам, как:
1) Оплата и регистрация платежей пластиковыми картами;
2) Кредитные операции через интернет;
3) Внесение или выдача средств со счёта;
4) Трансфер денежных средств между двумя электронными счетами через интернет.
Принципы:
1) Защита инициализации платежа, защита конфиденциальных данных об операции с использованием «сильной аутентификации клиента»;
2) Ограничение числа входов и попыток входов в систему, ограничение «таймаутов» соединения и сроков нахождения в системе;
3) Установка механизма мониторинга транзакций с целью предотвращения мошеннических операций;
4) Реализация многоуровневой системы безопасности с целью снижения рисков;
5) Консультирование клиентов о личной интернет-безопасности, предоставление инструментов по мониторингу и контролю за операциями.
«Сильная» аутентификация как процесс икак рекомендации иправила
Из анализа документов ЕЦБ и анализа предметной области в целом прослеживается явная путаница понятий и определений. ЕЦБ в документе «сильная (клиентская) аутентификация» даёт определение «сильной (клиентской) аутентификации», которое совпадает с определением многофакторной аутентификации. [2]
Таким образом, ЕЦБ понимает «сильную» аутентификацию как процесс и как набор рекомендаций, в которых фигурирует понятие «сильная» аутентификация, но это понятие совпадает с мультифакторной аутентификацией.
Очевидно, это также вносит некоторую путаницу, но всё же проясняет ситуацию.
Проблемы «сильной» аутентификации как процесса
В силу того, что очень часто, но не всегда, под процессом «сильной» аутентификации понимают мультифакторную аутентификацию, то стоит рассмотреть проблемы последней.
Основной проблемой мультифакторной аутентификации является проблема совместимости между устройствами, а именно стандартизация этих устройств (например usb-токенов).
При реализации системы многофакторной аутентификации требуется соблюдать полную независимость факторов.
Также проблемой многофакторной аутентификации является способ её реализации.
Например, если использовать в качестве одного из факторов фактор «я знаю», а именно классический «многоразовый» пароль, то это является серьёзной уязвимостью при работе с чужих компьютеров, например в интернет-кафе. Это подтолкнуло ведущих производителей рынка аутентификации к созданию аппаратных генераторов одноразовых паролей. Такие устройства генерируют очередной пароль либо по расписанию (например, каждые 30 секунд), либо по запросу (при нажатии на кнопку). Каждый такой пароль можно использовать только один раз.
Также проблема создания пользователя в системе неразрывно связана с тематикой пароля, что влечёт за собой ряд проблем.
Проблемы «сильной» аутентификации как набор рекомендаций
1) Видение процедуры аутентификации:
Под процедурой аутентификации подразумевается метод, по которому идентификационный номер передаётся пользователю и каким образом сертификаты передаются пользователям. Процесс аутентификации должен быть детально и качественно проанализирован на наличие уязвимостей. Лучший путь для решения этой проблемы — удаление человеческого фактора или сведение его к минимуму. Например, банковские сервисы передают конфиденциальную информацию с использованием робота (генератора речи по тексту или смс), исключая оператора.
2) «Место» аутентификации:
Очень часто алгоритм подтверждения подлинности пользователя расположен на серверах недоступных службе безопасности организации. Эти сервера, можно назвать местом аутентификации. Такие сервера должны быть детально обследованы.
Сам пользователь вводит пароль в web-форме браузера или мобильного телефона, поэтому пользовательский интерфейс или устройство, с которого происходит аутентификация, также можно назвать местом аутентификации. В идеале, они также должны быть защищены.
На практике гораздо проще взломать web-форму введения логина и пароля в окне браузера, нежели алгоритм подтверждения подлинности на сервере с сервисом или базой данных.
3) Защита персональных идентификационных данных:
Данные участвующие в идентификации должны также являться конфиденциальными и к ним должны применяться такие же средства защиты, которые применяются к хранению паролей.
Например, телефонный номер не может выступать паролем, так как является публичной информацией. В реальных системах иногда встречаются такие уязвимости, часто в корпоративных системах. [3]
4) Аутентификация как процесс:
Процесс «сильной» аутентификации подразумевает под собой многофакторную и проблемы последней были перечислены ранее. Это отдельный класс задач, и «сильная» аутентификация наследует их.
5) Усталый пользователь:
Обременяя пользователя дополнительными мерами аутентификации, система рискует утомить его. Усталый пользователь может часто вводить неправильный пароль. Группа таких пользователей может создать шум для системы мониторинга атак. Меры предосторожности должны быть гибкими и адекватными, по мере возможностей подстраиваться под каждого пользователя.
Например, в системах с аутентификацией по логину, паролю и смс-оповещению с одноразовым паролем, часто происходит задержка смс из-за проблем со связью, в результате пользователь может несколько раз инициализировать отправление смс, что вызовет подозрение у системы мониторинга атак, которая блокирует усталого пользователя.
Такие погрешности стоит учитывать, например, добавив к варианту «выслать одноразовый пароль повторно» вариант «мне ничего не пришло». Необходим баланс между удобством сервиса и его защищённостью.
Решение
Не всегда организации удаётся в одиночку справиться с некоторой проблемой или решить её достаточно качественно. В таких случаях фирмы часто объединятся в консорциумы (временное объединение независимых предприятий иорганизаций сцелью координации их предпринимательской деятельности). По такому же принципу и возник консорциум FIDO Alliance.
Целью возникновения FIDO Alliance в феврале 2013 года стало совместное решение следующих проблем: проблем совместимости между устройствами «сильной» аутентификации, проблем создания пользовательских лиц и хранения многоразовых имён и ключей. Основателями консорциума являются компании PayPal and Lenovo.
На сегодняшний день в FIDO Alliance участвуют крупнейшие корпорации, такие, как Alibaba Group, ARM, Bank of America, Google, Daon и многие другие.
FIDO Alliance занимается спецификацией полного спектра аутентификационных технологий, включающих в себя биометрию: сканирование сетчатки глаза или отпечатка пальца, распознавание голоса или лица, а также спецификацией существующих решений и стандартов связи: TMP, USB токены, eSE, умные карты и NFC. Спецификация отражает модель работы вышеперечисленных устройств и их основной принцип действия.
Спецификация FIDO подразумевает 2 типа пользователей. Первый тип предполагает взаимодействие с универсальным двухфакторным протоколом аутентификации (U2F), второй тип использует универсальный аутентификационный протокол (UAF). Оба стандарта определяют общий интерфейс клиента для локального метода аутентификации пользователя.
Клиентская часть может быть предустановлена на локальное устройство как отдельная программа, или быть частью браузера.
В процессе работы был проведён анализ предметной области, в рамках которого была выявлена проблема неточности понятий и определений. В ходе дальнейшего анализа предметной области была внесена ясность по средствам уточнений и контекстов.
Далее была найдена иерархическая связь между этими определениями.
Также были проанализированы основные современные проблемы «сильной» аутентификации в общем понимании этого определения.
В заключение было проанализировано возможное решение этих проблем — два семейства протоколов U2F и UAF от FIDO.
Литература:
- Интернет энциклопедия [Электронный ресурс]: Strong_authentication. URL: https://en.wikipedia.org/wiki/Strong_authentication (дата обращения: 11.09.2016).
- ECB [Электронный ресурс]: ECB releases final Recommendations for the security of internet payments and starts public consultation on payment account access services. URL: http://www.ecb.europa.eu/press/pr/date/2013/html/pr130131_1.en.html (дата обращения: 11.09.2016).
- IDENTITY & ACCESS MANAGEMENT [Электронный ресурс]: The Problem With Two-Factor Authentication. URL: http://www.darkreading.com/identity-and-access-management/the-problem-with-two-factor-authentication/d/d-id/1113697 (дата обращения: 11.09.2016).
- Handbook of Applied Cryptography [Электронный ресурс]: The Cryptography Handbook. URL: http://cacr.uwaterloo.ca/hac (дата обращения: 11.09.2016).
