Когда пароль не работает: вторичная аутентификация сайтов

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

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

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

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

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

Механизмы вторичной аутентификации

В 2008 году представитель правоохранительных органов смог взломать аккаунт почты кандидата в президенты США Сары Пэйлин, угадав по общедоступной информации ответ на ее секретный вопрос "Где вы познакомились с вашим будущим супругом?", а годом позже французский хакер получил и выложил в открытый доступ конфиденциальные сведения из взломанных им учетных записей руководителей компании Twitter. Для взлома он воспользовался двумя методами: угадал ответы на контрольные вопросы и инициировал отправку сообщения с инструкциями по сбросу пароля на принадлежащий ему почтовый ящик.

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

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

• Надежность — вероятность того, что владелец аккаунта успешно аутентифицируется.
• Защищенность — вероятность того, что атакующий может выдать себя (ложно аутентифицироваться) в качестве владельца аккаунта; либо значительные время и энергия, необходимые на решение такой задачи. Для каждого из видов угроз, как правило, требуются свои дополнительные критерии оценки.
• Выгодность аутентификации — ресурсные затраты владельца аккаунта на выполнение аутентификации, а также любые затраты, которые несет веб-сервис.
• Выгодность настройки — ресурсные затраты владельца аккаунта, а также объем раскрытых им личных данных при конфигурировании и перенастройке механизма аутентификации плюс издержки веб-сервиса при этих процессах.

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

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

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

Механизмы на основе знаний

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

Контрольные вопросы. Контрольные, или «секретные», вопросы опираются на предположение, что владельцы аккаунта легко могут ответить на них, а атакующие — нет. Цена настройки контрольного вопроса относительно невелика — пользователь выбирает один из вопросов и указывает ответ на него, который нужно будет дать сайту, когда соответствующий вопрос будет использоваться для аутентификации. Исследователи нередко делят контрольные вопросы на две группы: вопросы, требующие фактической информации о пользователях (например: "Название вашей первой школы"), или вопросы о их мнениях и предпочтениях (например: "Ваш любимый исполнитель").

Контрольный вопрос может не сработать, если ответ:

• нельзя задать при настройке — на некоторые вопросы нельзя дать ответ, если они неприменимы к пользователю (например, «Кличка вашего первого домашнего животного») или если пользователь во время настройки не знает ответа (пример: «Номер вашей библиотечной карточки»);
• легко забыть — пользователь может забыть содержание или формулировку ответа, данного им при конфигурировании. Это особенно часто случается с вопросами о предпочтениях, которые могут со временем меняться (пример: «Ваша любимая песня»);
• известен — атакующим может оказаться человек, знающий ответ, например родственник или друг;
• можно угадать — верный ответ на вопрос может быть популярным или выбранным из небольшого набора вероятных. В последнем случае появляется уязвимость для атак, состоящих в переборе ответов, наиболее популярных среди пользователей или среди узкого их круга, к которому принадлежит конкретный пользователь. Например, в США «Джордж Вашингтон» — популярный ответ на вопрос «Ваша любимая историческая личность»;
• можно выяснить — верный ответ можно найти в Интернете или выяснить у знающего человека.

Исследования по проблеме контрольных вопросов велись еще в конце 80-х годов, и результаты даже самых первых изысканий указывают на нецелесообразность использования всего одного вопроса в качестве аутентификатора. Но, поскольку на многих сайтах все же используется всего один вопрос, можно предположить, что сами вопросы за прошедшие десятилетия стали более надежными. Однако, как показало проведенное в 2008 году исследование, контрольные вопросы, предлагаемые четырьмя крупнейшими провайдерами почты, были неудовлетворительными. У половины вопросов были ответы, которые по меньшей мере 20% пользователей забывали в течение полугода. На половину вопросов при конфигурировании были даны ответы, на которые не меньше чем в 15% случаев мог дать ответ кто-либо из знакомых пользователя, которым он не доверяет. Все вопросы не срабатывали по крайней мере по одной из перечисленных причин не меньше чем у 9% пользователей. Ни один из вопросов не был достаточно надежен и защищен, чтобы его можно было использовать для аутентификации сам по себе.

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

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

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

Во-вторых, для возврата пользователю доступа к учетной записи провайдеры могут потребовать от него ответа на несколько контрольных вопросов. Это укрепляет защищенность, но может увеличить вероятность забывания ответов. Провайдер может снизить этот риск, если потребует дать определенную долю верных ответов на еще большее количество вопросов. Однако данный подход тоже довольно неудобен, особенно если учесть, что хороших контрольных вопросов немного. Примером качественной системы, наращивающей количество вопросов, может служить схема аутентификации на основе предпочтений, разработанная под руководством Маркуса Джекобссона. Она уменьшает энергозатраты на каждый вопрос, размещая ответы на шкале Ликерта, вместо того чтобы предоставить пользователю возможность отвечать в свободной форме. Однако данная схема требует, чтобы пользователь ответил на 15 контрольных вопросов как при конфигурировании, так и при аутентификации.

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

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

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

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

Транзитивные механизмы вторичной аутентификации

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

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

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

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

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

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

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

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

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

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

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

Разработка стратегии вторичной аутентификации

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

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

Используйте комбинированные механизмы аутентификации

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

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

Предоставьте контроль самим пользователям

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

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

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

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

Регулярно проверяйте и обновляйте сведения

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

Изменяйте требования к защищенности в зависимости от активности

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

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

Разрабатывайте с расчетом на то, что аккаунт может быть скомпрометирован

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

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

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

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

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

***

Существует множество механизмов вторичной аутентификации и вариантов их настройки; каждый из них обеспечивает различное соотношение между уровнями надежности, защищенности и выгодности. Для большинства сайтов достаточно лишь несложных механизмов аутентификации. Однако операторам сайтов, учетные записи на которых имеют более высокую ценность, например сервисов почты, следует более тщательно подходить к разработке систем вторичной аутентификации. Рекомендуется скомбинировать несколько механизмов, что позволит адаптировать систему в соответствии с индивидуальными потребностями владельца аккаунта в защищенности и надежности. Рекомендуется также регулярно освежать аутентификационные сведения — предлагать пользователям подстраивать параметры аутентификации в зависимости от активности использования учетной записи. Кроме того, систему аутентификации необходимо проектировать исходя из предположения о том, что аккаунты будут компрометироваться.

Роберт Ридер (roreeder@microsoft.com) — старший менеджер по программе Microsoft Usable Security; Стюарт Шехтер (tus@microsoft.com) — научный сотрудник Microsoft Research.