Семь проблем управления идентификацией

Системы управления идентификацией на основе Web — сложные образования с мощной функциональностью и множеством потенциально уязвимых мест. Их цель — обеспечить управление процессом идентификации, учетными данными, личной информацией и представлением этих данных третьим лицам. Во многих схемах провайдеры идентификации (identity provider, IdP) назначают пользователям учетные данные, а проверяющая сторона (relying party, RP) доверяет поставщику проверить подлинность пользователя, прежде чем ему будет предоставлен доступ к Web-сервисам. Благодаря разделению ролей IdP и RP пользователи могут применять один идентификатор во многих Web-сервисах.

Некоторые схемы управления идентификацией централизованы: единый центр функционирует как IdP, проверяя подлинность пользователей и выдавая маркеры идентификации, принимаемые и другими организациями. Пример такой модели — Microsoft Passport (www.passport.com ). Централизованные системы закрыты, и связь между IdP и RP в них должна устанавливаться заранее.

В децентрализованных системах может быть более одного IdP: пользователь, RP (выполняющий также функции IdP), кооперативная группа RP или специализированный IdP. Децентрализованным системам необходимы общие протоколы для обмена идентификаторами и подтверждениями авторизации между IdP и RP. Примеры общих протоколов: комплекс OASIS WS-Federation (www.oasis-open.org/committees/wsfed ), OpenID (www.openid.net ), Security Assertion Markup Language (SAML, www.oasis-open.org/committees/security ) компании Liberty Alliance, Microsoft Cardspace (Cardspace.netfx3.com) и Higgins Project (www.eclipse.org/higgins). Рассмотрим децентрализованные системы, которые теоретически не требуют предварительного согласования между IdP и RP.

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

Семь проблем управления идентификацией

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

Управление идентификацией — не самоцель

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

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

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

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

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

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

На рынке есть несколько пакетов, с помощью которых пользователи могут защитить и осуществлять управление своими удостоверениями, например модули расширения браузера Sxipper (www.sxipper.com) и OpenID Seatbelt Plugin (pip.verisignlabs.com/seatbelt.do), повышающие безопасность протокола OpenID. Однако большинство пользователей не покупают и не обновляют программы укрепления безопасности. Мало того, опросы показывают, что вообще далеко не все пользователи регулярно применяют программы безопасности, а если применяют, то переоценивают их надежность [5, 6].

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

Когнитивная масштабируемость столь же важна, как и техническая

Сегодня пользователям приходится нести бремя управления постоянно растущим числом удостоверений, что четко видно из так называемой «усталости от паролей». В среднем на каждого пользователя приходится примерно по 25 учетных записей, требующих пароли (часто вводят по восемь паролей в день), поэтому, чтобы облегчить запоминание, они выбирают одинаковые или похожие пароли для различных учетных записей и, по возможности одинаковые или похожие имена входа [7, 8].

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

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

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

Согласие пользователей грозит разглашением информации

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

Получая на экране предупреждения об опасности, пользователи, как правило, пропускают текст и быстро закрывают диалоговые окна, редко представляя себе последствия условий, на которые они только что согласились [12, 13]. Более того, они привыкают к предупреждениям и после многократного повторения перестают обращать на них внимание [14, 15]. Пользователи также начинают игнорировать похожие, но различающиеся предупреждения, даже если они возникают в других ситуациях. Если пользователю поступает запрос на передачу информации через легко отменяемые механизмы, то он может дать согласие, если полагает данный способ самым простым для достижения цели, независимо от соответствия данного действия условиям конфиденциальности и безопасности.

В интерфейсе Microsoft CardSpace пользователи могут согласиться на автоматическую пересылку данных. Для этого им нужно зарегистрироваться на Web-сайтах, выбирая «карту идентификации», которая будет представлена на сайте (рис. 1, a). При желании пользователь может просмотреть и изменить эти данные (рис. 1, б). Можно предположить, что большинству пользователей затруднительно просматривать и одобрять каждое поле пересылаемых данных. Вместо этого они выберут более простой путь входа и выполнения задачи — одобрить отправку всех данных. В этом случае пользователи могут отправить больше информации, чем необходимо, или передать ее не тому, кому следует.

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

Нужна взаимная проверка подлинности

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

Запустить атаки с использованием погрешностей идентификации против современных систем проверки подлинности и программного обеспечения очень просто. Взломщики могут имитировать элементы пользовательского интерфейса Web-сайта, включая контент и индикаторы безопасности сайта или программы. Большинство пользователей не могут отличить подлинный Web-сайт от сайта фишинга, построенного для перехвата идентификаторов и учетных данных [4, 17]. В одном эмпирическом исследовании выяснилось, что ежегодно 1,5% пользователей отсылают пароли на Web-сайты фишинга [7]. Федеративные системы проверки подлинности, в которых пользователи могут вводить один набор учетных данных на многих сайтах, только повышают ценность учетных данных как объекта фишинга.

Еще опаснее ситуация, возникающая при перенаправлениях HTTP, как это сделано в OpenID (www.openid.net ), Yahoo Browser Based Authentication (developer.yahoo.com/auth) и Google AuthSub (code.google.com/apis/accounts/docs/AuthForWebApps.html). Привлекательность схем на основе перенаправления заключается в том, что поставщики могут использовать удостоверения, не требуя от пользователя загружать новые программы. К сожалению, в этом случае запускать атаки фишинга становится еще проще. В этих схемах RP-пользователи предоставляют сведения о своем IdP, а Web-сайт RP перенаправляет их для регистрации в IdP. Взломщику достаточно организовать сайт RP с привлекательным содержимым. Учитывая, что пользователи должны сообщить о своем IdP проверяющей стороне, взломщики располагают всей необходимой информацией, чтобы подделать Web-сайт IdP. Они могут перенаправить пользователя из своего Web-сайта на ложный Web-сайт IdP и перехватить учетные данные пользователя. Существует и множество других, более сложных вариантов нападения.

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

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

Протоколы должны обеспечивать взаимную проверку подлинности (текущие стандарты проверки подлинности рабочей группы IETF для HTTP не поддерживают взаимную проверку [18]). Подделать пользовательские интерфейсы должно быть трудно — пользователь должен иметь возможность убедиться, что установил связь с настоящим партнером, как при прямой проверке подлинности, так и при использовании заимствованных удостоверений. Современные интерфейсы и индикаторы безопасности не согласованы между различными браузерами и операционными системами, что увеличивает риск ошибки пользователя из-за плохого знакомства с интерфейсом [4]. Устранить эту проблему помогает взаимодействие внутри отрасли и развитие стандартов, например проектируемых рабочей группой W3C Web Security Context.

Проверяющая сторона стремится контролировать среду потребителя

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

Поставщики удостоверений еще больше запутывают пользователя. Например, к кому должен обращаться пользователь для устранения ошибок — к поставщику удостоверений или проверяющей стороне? Владельцы сайтов неохотно участвуют в схемах на основе перенаправления, в которых требуется, чтобы пользователи посещали страницу другого Web-сайта или использовали внешний программный интерфейс. После того как внимание пользователя было направлено на другой предмет, есть вероятность, что он уже не вернется. Многие разработчики предлагали способы уменьшения числа переходов между RP и IdP. Например, некоторые модули расширения браузера, такие как Verisign OpenID Seatbelt Plugin (https://pip.verisignlabs.com/seatbelt.do ), позволяют пользователям выполнить процедуру входа один раз для поставщика удостоверения и остаться зарегистрированными, чтобы пользователям не приходилось покидать Web-узел проверяющей стороны. Другие скрывают сам факт связи пользователя с IdP и скрыто устанавливают связь с IdP от имени пользователя (например, Sxipper.com).

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

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

Доверие необходимо заработать

Кому пользователи могут доверить свою личную информацию? Это сложное решение, связанное с оценкой риска, и, к сожалению, люди часто неудачно оценивают риск, особенно когда речь идет о конфиденциальности и безопасности [6].

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

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

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

Рекомендации

Концепция управления удостоверениями не нова. Несмотря на долгую историю инициатив — Microsoft Passport и Hailstorm, сервисы защиты удостоверений типа Zero Knowledge Systems (www.freedom.net ) и др. — все они оказались неудачными, отчасти потому, что игнорировали упомянутые здесь факторы.

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

Приведем рекомендации для разработчиков систем управления идентификацией:

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

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

Литература

1. A. Acquisti, J. Grossklags, Privacy and Rationality in Decision Making. IEEE Security & Privacy, vol. 3, no. 1, 2005.
2. B. Fitzpatrick, D. Recordon, Thoughts on the Social Graph. http://bradfitz.com/social-graph-problem/.
3. A. Adams, M.A. Sasse, Users Are Not the Enemy: Why Users Compromise Security Mechanisms and How to Take Remedial Measures. Comm. ACM, vol. 42, no. 12, 1999.
4. R. Dhamija, J.D. Tygar, M. Hearst, Why Phishing Works. Proc. Conf. Human Factors in Computing Systems (CHI 06), ACM Press, 2006.
5. McAfee-NCSA Online Safety Study, Oct. 2007.
6. AOL/NCSA Online Safety Study, Dec. 2005.
7. D. Florencio, C. Herley, A Large Scale Study of Web Password Habits. Proc. Int’l Word Wide Web Conf. (WWW 07), ACM Press, 2007.
8. R. Dhamija, A. Perrig, Dejа Vu: A User Study Using Images for Authentication. Proc. 9th Usenix Security Symp., Usenix Assoc., 2000.
9. B.M. Gross, E.F. Churchill. Addressing Constraints: Multiple Usernames Task Spillage and Notions of Identity. Proc. Conf. Human Factors in Computing Systems:Extended Abstracts (CHI 07), ACM Press, 2007.
10. K. Cameron, Laws of Identity. blog, May 2005; ww.identityblog.com/stories/2004/12/09/thelaws.html.
11. E. Maler, r-e-s-p-e-c-t. blog, 19 June 2006; www.xmlgrrl.com/blog/archives/2006/06/19/r-e-s-p-e-c-t/.
12. N. Good et al., Stopping Spyware at the Gate: A User Study of Privacy, Notice, and Spyware. Proc. Symp. Usable Privacy and Security (SOUPS 05), ACM Press, 2005.
13. J. Grossklags, N. Good. Empirical Studies on Software Notices to Inform Policy Makers and Usability Designers. Proc. Usable Security (USEC 07), Lecture Notes in Computer Science, Springer, 2007.
14. M.S. Wogalter and W.J. Vigilante, “Attention Switch and Maintenance,” Handbook of Warnings, M.S. Wogalter, ed., Lawrence Erlbaum Assoc., 2006.
15. D.A. Norman, Design Rules Based on Analyses of Human Error. Comm. ACM, vol. 26, no. 4, 1983.
16. B. Schwartz, “The Tyranny of Choice,” Scientific Am., Apr. 2004.
17. S. Schechter et al., The Emperor’s New Security Indicators. Proc. IEEE Symp. Security and Privacy, IEEE CS Press, 2007.
18. J. Franks, et al., RFC2617: HTTP Authentication: Basic and Digest Access Authentication. June 1999.
19. Privacy Rights Clearinghouse, Chronology of Data Breaches. www.privacyrights.org/ar/ChronDataBreaches.htm.
20. R. Stern, What Happened in Vegas... Phoenix New Times, 31 May 2007.

Рахна Дхамиджа (rachna@seas.harvard.edu ) — сотрудник центра исследований по проблемам компьютерных технологий и общества Гарвардского университета;
Лиза Дюссо (ldusseault@commerce.net ) — сотрудник CommerceNet, директор IETF Applications Area, автор книги WebDAV: Next-Generation Collaborative Web Authoring.