Реалии и проблемы многофакторной аутентификации

Конявская С. В., АО «ОКБ САПР», кафедра защиты информации ФРКТ МФТИ

В этом номере снова обратимся к вопросу «факторов» аутентификации и, не стоит скрывать, снова в критическом ключе. В опубликованной в прошлом номере статье[1] упомянуто, что ни при каких действиях с аутентифицирующими данными, классифицированными по «факторам», эти самые факторы не используются. Единственное их применение – это построение идеологемы «многофакторная аутентификация». Рассмотрим связанные с этой идеологемой реалии и вытекающие из них проблемы.

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

Мантры, или «количество перейдет в качество»

Идея, мотивирующая многофакторность, сводится обычно примерно к следующим выкладкам: при многофакторной аутентификации злоумышленнику нужно украсть кроме пароля еще и токен, а это сложнее сделать незаметно. Еще сложнее – незаметно украсть глаз или руку. Это, в принципе, так и есть. Но важно ли это?

Это важно, если мы представляем себе атаку, при которой злоумышленник собирается физически прийти на рабочее место жертвы и там все это предъявлять — токен, глаз и руку. В этом случае, действительно, существенно быстрее и проще добыть один пункт номенклатуры, чем несколько. Здесь можно согласиться с тем, что подготовка такой атаки – с физическим доступом к компьютеру жертвы – несколько упрощается по мере снижения количества применяемых аутентификаторов.

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

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

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

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

Количество не всегда переходит в лучшее качество. Если иметь две руки человеку предпочтительнее, чем одну, то иметь три – вряд ли предпочтительнее, чем две.

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

Ошибки чувственного восприятия, или «чем ниже голова, тем глубже мысли»

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

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

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

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

Факторы поважнее «факторов»

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

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

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

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

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

Однако и тут играет роль не «фактор», а сменяемость или несменямость данных: пароль, токен и папиллярный узор компрометируются одинаково легко (или сложно), но первые два можно немедленно сменить, а третий – нет.

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

Неотделимые аутентифицирующие признаки хороши до тех пор, пока предъявить их может только тот, от кого они неотделимы.

А можно ли вообще это обеспечить?

Как перестать гнаться за количеством

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

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

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

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

В то же время, еще в XIX веке сформулирована максима, ошибочно приписываемая Марксу, о том, что нет такого преступления, на которое капитал не готов ради 300% прибыли.

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

Не числом, а умением

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

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

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

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

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

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

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

[1] Конявская С. В. Проблемы использования биометрии в качестве фактора аутентификации // Information Security/Информационная безопасность. М., 2023. № 2. С. 32–35.

[2] Обычно комбинируется считыватель того или иного биометрического признака и какого-либо аппаратного идентификатора, но есть и другие примеры, например, токены с клавиатурой на корпусе.

Автор: Конявская С. В.

Дата публикации: 31.07.2023

Библиографическая ссылка: Конявская С. В. Реалии и проблемы многофакторной аутентификации.// Information Security/Информационная безопасность. М., 2023. № 3. С. 64-65.

---