Многофакторная аутентификация

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

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

Виды аккаунтов

Сильная аутентификация нужна не для всех аккаунтов. Их можно поделить на следующие категории в зависимости от ценности:

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

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

Распространенные угрозы

Трудность соблюдения баланса между защищенностью и удобством использования вынуждает отказаться от сложных правил формирования паролей и искать нечто получше. Неэффективность систем парольной аутентификации можно проиллюстрировать следующими нашумевшими примерами: угон Google-аккаунта писательницы Деборы Фэллоуз, в результате которого она едва не потеряла всю свою корреспонденцию за шесть лет; компрометация электронной почты Сары Пэлин в канун предвыборной гонки 2008 года и захват аккаунтов журналиста Мэта Хонана на целом ряде онлайн-сервисов, включая Google, Twitter и AppleID.

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

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

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

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

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

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

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

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

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

Аппаратная авторизация

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

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

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

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

Двухэтапная верификация

В качестве своей первой системы авторизации, выполняемой с помощью клиентских устройств, компания Google предложила схему двухэтапной верификации (two step verification, 2sv). Как показано на рисунке, когда пользователь заходит в Google с нового компьютера (после прохождения традиционной аутентификации по имени-паролю), от него требуют еще ввести шестизначный код подтверждения. Он может быть прислан по SMS, сообщен путем голосового звонка на заранее зарегистрированный телефон, сгенерирован предустановленным на смартфоне офлайн-приложением либо взят из заранее составленного перечня разовых кодов. Конкретный метод можно выбрать на странице настроек аккаунта. Отправка кода создает неустаревающий cookie, по которому браузер распознает пользовательское устройство в качестве дополнительного фактора аутентификации — или доверенного компьютера — для всех последующих процедур входа.

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

Пользователи могут отозвать свои доверенные компьютеры, зайдя в настройки по адресу accounts.google.com/security. Отметим, что в результате такого отзыва не удаляются данные, кэшированные на локальном диске. В качестве первой линии защиты от хищения данных рекомендуется пользоваться файловой системой с шифрованием или механизмом разграничения пользовательских прав на уровне ОС.

Опыт Google с 2sv оказался успешным — системой пользуются миллионы, и сегодня это одно из самых крупномасштабных внедрений двухфакторной аутентификации в мире. После скандала с Мэтом Хонаном 2sv подключили почти четверть миллиона пользователей — к безопасности люди начинают относиться серьезнее, когда пострадал их знакомый или публичная фигура. Как показало изучение информации по кражам аккаунтов высокопоставленных чиновников, среди сотен из тех, чьи пароли были украдены путем фишинга, не пострадали только двое — они пользовались 2sv.

Однако далеко не все пользователи Google применяют 2sv, и доля вины в этом кроется в несовершенстве системы и документации. Но в компании продолжают шлифовать неровности; например, чтобы минимизировать время настройки, пользователю рекомендуется доставлять коды 2sv по SMS или голосовыми звонками. Примерно 10% клиентов Google впоследствии устанавливают также смартфонное приложение для генерации кодов, которому для работы не требуется ни сотовая связь, ни даже зарегистрированный номер телефона.

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

Многие запаслись резервными способами получения кодов — например, по домашним или рабочим фиксированным телефонам, через телефон члена семьи, друга либо просто распечатанным списком кодов. Такие пользователи обычно сами могут восстановить доступ после утраты основного генератора кодов 2sv. Как выяснилось, помощь редко требуется и пользователям офлайн-генератора кодов для смартфона, однако применение 2sv затруднено для пользователей клиентских приложений, поддерживающих только традиционный вход по имени-паролю. Типичный пример — почтовые клиенты для ПК и некоторых смартфонов, работающие по протоколу IMAP. Для таких случаев в Google предлагают переходную функцию — «пароль приложения» (application-specific password, ASP), машинно-генерируемый пароль с высокой энтропией, который трудно запомнить и, соответственно, непросто добыть фишингом. Когда такое приложение пытается получить доступ к вашему аккаунту Google, то в ответ на запрос пароля нужно ввести ASP. Но ничего не значащий для пользователя набор символов сложно запомнить, поэтому предпочтительно, чтобы на клиентских платформах применялась централизованная модель управления аккаунтами с возможностью входа через браузер, как это делается в Android. Еще одно слабое место ASP — ошибочное представление о том, что такой пароль только одному приложению предоставляет доступ к аккаунту. (Решением служит протокол OAuth, обсуждаемый далее.)

В Android, начиная с версии Ice Cream Sandwich, пользователи 2sv могут в браузере настроить свои смартфоны — система предлагает такую возможность, требуя дополнительный фактор аутентификации. Во время регистрации отображается адаптируемый пользовательский интерфейс, включающий в себя запрос фактора 2sv, что устраняет необходимость в ASP. Более того, централизованная модель управления аккаунтом в Android отменяет для многих приложений необходимость требовать от пользователя ввода одного и того же пароля и кода 2sv. Взамен приложения запрашивают у системного диспетчера аккаунтов краткосрочные токены для доступа к требуемым данным. Таким образом, пользователям Android проще настраивать 2sv.

Вначале в Google рассматривали 2sv как элемент системы аутентификации пользователей, аналогичный аппаратным генераторам одноразовых паролей, широко применяемым на предприятиях для удаленного входа, и, чтобы сделать 2sv более практичной для широкого круга пользователей, частота верификации, заданная по умолчанию, была ограничена одним разом в месяц. Но выяснилось, что 30 дней — это либо слишком мало, либо слишком много. Запросы токенов нередко раздражают и дезориентируют, когда выводятся в каждом браузере на каждом устройстве. К тому же, если пользователь потеряет смартфон, не находящийся в режиме блокировки, месяца может быть вполне достаточно для взлома аккаунта. Поэтому в Google решено было применять 2sv прежде всего как средство перманентной авторизации клиентского устройства — пользователи по желанию могут перейти на старый способ применения (на странице подтверждения 2sv есть кнопка-флажок, отключенное состояние которой указывает на то, что срок действия cookie 2sv должен истекать по окончании сеанса работы в браузере, а не храниться постоянно).

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

Между прочим, выяснилось, что двухэтапной верификацией злоупотребляют взломщики аккаунтов. После кражи пароля к аккаунту и его взлома злоумышленники подключают 2sv (на свой номер телефона) лишь для того, чтобы затруднить восстановление аккаунта истинным владельцем. Известны единичные случаи этого явления в World of Warcraft — одном из немногих сервисов, широко внедривших двухфакторную аутентификацию.

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

Токен USB с функциями смарт-карты

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

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

Первая реализация подобного решения в Google представляет собой экспериментальный токен USB для 2sv, работающий без дополнительных драйверов в любых ОС, которые поддерживают USB-клавиатуру. Высокоуровневый протокол, регламентирующий формат пакетов для получения заверенных подтверждений от токена (выполненного в виде брелка), может исполняться на уровне приложения в хостовой ОС. Брелок имеет сенсорную область, при касании которой генерируется одноразовый код.

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

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

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

Понятно, что для привлечения большего числа пользователей нужно предложить аутентификационное устройство в нескольких формфакторах. Брелок USB обладает компактной сертифицированной «прошивкой», являющейся трудной мишенью для вредоносных программ, однако необходимость носить с собой дополнительный брелок вряд ли понравится многим потребителям. Можно интегрировать такой ключ в смартфон или встроить в украшение; например, смартфон или перстень со встроенной смарткартой могли бы авторизовать новый компьютер путем простого постукивания по нему, причем для этого не понадобится наличие сотовой связи. Многим пользователям в путешествиях приходится заходить на привычные сервисы с новых компьютеров, и, как показывает практика, наибольшую техническую сложность при этом представляет не реализация криптографии, а отсутствие на потребительских платформах стандартного интерфейса, обеспечивающего возможность взаимодействия между устройствами. В Google на эту роль пробуются технологии незащищенной радиосвязи (протокол Bluetooth RFCOMM) и NFC.

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

Привязка cookie к шифрованному каналу

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

При вводе имени и пароля на входе в сайт либо кода 2sv для аутентификации клиентского устройства в локальном хранилище браузера создается файл cookie. В браузерах применяется ряд мер, защищающих cookie от кражи вредоносным JavaScrpit-кодом. Однако такие cookie все же менее защищены, чем закрытые ключи, ассоциированные с клиентскими SSL-сертификатами, которые могут храниться в защищенной области операционной системы или под аппаратной защитой, например, в Trusted Platform Module или смарткарте. Так почему бы не использовать вместо cookie клиентские сертификаты и секретные ключи сеансов SSL? Клиентские сертификаты существовали еще на заре WWW, но не получили популярности из-за сложного пользовательского интерфейса их установки, состоящего из серии всплывающих браузерных или системных окон. Использование единственного клиентского сертификата было бы ошибкой с точки зрения безопасности, так как появляется возможность отслеживания процесса, а управление несколькими сертификатами было бы слишком сложным для пользователя. С учетом этого, а также широты применения cookie и объема прикладного ПО, которое пришлось бы обновлять, идея перехода на клиентские сертификаты выглядит сомнительной. Но есть новый, весьма перспективный подход — автоматическая криптографическая привязка cookie к SSL-клиенту. Когда браузер впервые обращается к новому домену, тот автоматически генерирует пару ключей, которые используются для последующих SSL-соединений с ним. Если привязать cookie или иной идентификатор к такому клиентскому ключу, то эти идентификаторы можно будет использовать только внутри соединений, инициируемых данным клиентом. В результате перехватчик сеанса не сможет воспроизвести его со своей системы.

В Google привязку к каналу реализовали с использованием криптоалгоритма на эллиптических кривых P256 — вместо самоподписанного сертификата X.509 был задействован сам открытый ключ, а вычислительная и сетевая нагрузка оказались низкими, несмотря на дополнительные TCP-соединения. В типичной сервисной архитектуре механизм приема SSL-сеанса на фронтальном сервере передает открытый ключ клиента (или хэш ключа) серверу, на котором поддержку привязок к каналу можно реализовать постепенно, по мере готовности. Соответствующая функция, получившая название Channel ID, в браузере Chrome версии 24 внедряется прозрачно для пользователей. Такое «безмолвное» укрепление платформы — лучший способ ввода новых средств безопасности. Сообразно принципам минимализма пользовательского интерфейса Chrome, при удалении истории просмотра либо cookies и данных сайтов автоматически сотрутся и пары ключей для соответствующих доменов. Отметим, что для альтернативных профилей браузера и режима инкогнито используются отдельные пары ключей, так же как cookie и данные сайтов.

Применение аппаратного криптопроцессора TPM, встроенного во многие ноутбуки, — хороший способ защиты частных ключей сеансов и ограничения потерь от вредоносных программ. В Google надеются, что инициативы компании подтолкнут производителей оборудования к более широкому внедрению быстродействующих модулей TPM. Тем временем в компании планируют поэкспериментировать с применением USB-брелков в качестве квазиперманентного защищенного элемента компьютера. Такой брелок мог бы стать своего рода «ключом зажигания», который, как только его вынимают, блокирует пользовательский компьютер.

Серверные технологии

Что касается аутентификации серверов клиентскими устройствами, то тут ситуация лучше — большинство браузеров поддерживают проверку SSL-сертификатов, а на сайтах для предотвращения атак нижнего уровня можно задействовать механизм HTTP Strict Transport Security. Конечно, нужно сохранять бдительность в связи с возможными ошибками в протоколе SSL и его реализациях, а также компрометацией серверных ключей, но наибольший риск создают атаки «человек посередине», приводящие к взлому корневых удостоверяющих центров, как это было с DigiNotar. Эти редкие атаки со временем могут стать распространенными, поэтому в Google уделяют значительное внимание разработкам в области прозрачности сертификатов и смежных концепций.

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

Важная часть системы аутентификации — механизм анализа рисков, работающий прозрачно для пользователя. Серверная проверка рисков позволяет ограничить масштаб угона аккаунтов у пользователей со слабыми или дублирующимися паролями. Если в 2sv и иных двухфакторных системах используется «что-то, что мы знаем» и «что-то, что мы имеем», то механизм контроля рисков проверяет место, где вы находитесь, и ваше поведение. Например, подозрения может вызвать нарушение обычного географического местонахождения вашего IP-адреса. Сервер в связи с этим может выдать предупреждение, как делает веб-интерфейс Gmail при обнаружении необычной страны входа. Как и при анализе рисков кредитных карт, при реализации таких систем нужно принимать во внимание, что человек может находиться, например, в отпуске. В случаях более отчетливых признаков риска оправданным будет заставить пользователя ответить на дополнительные вопросы для удостоверения личности. Некоторые из признаков риска могут быть достаточно сложными, например базирующимися на результатах оценки поведения пользователя после входа в аккаунт. Следует отметить, что достаточно сложно разработать основанные на оценке рисков системы предупреждений и запросов, которые бы не создавали дополнительных возможностей для фишинговых атак.

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

Сервисные аккаунты и делегирование

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

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

Современное решение этой проблемы — «сервисные аккаунты» из мира облаков. Облачной инфраструктуре можно доверить подтверждение «личности» программы как для внутренних систем, так и для внешних. Облака при этом хранят аналог смарткарты с частным ключом, который используется от имени программы. Рассмотрим, например, приложения, работающие поверх Google App Engine (GAE) — здесь могут использоваться три типовые схемы.

GAE предоставляет встроенные ресурсы с приватным содержимым, например Datastore. Когда приложение получает идентификатор для взаимодействия с Datastore, то выполняется обязательная аутентификация, поэтому любые данные, помещаемые приложением в Datastore, будут доступны только последующим экземплярам этого приложения, но не другим.
GAE предоставляет приложению возможность обращения к ресурсам, участвующим в аутентификационной экосистеме Oauth, — например, GAE-приложение под названием 1234567@appspot.gserviceaccount.com получает токен OAuth, действительный в течение часа и только для вызовов API Google Docs.
GAE выполняет низкоуровневые согласования, позволяя приложению общаться с проприетарными архитектурами. Допустим, приложению нужно аутентифицировать себя для шлюза в определенном банке, служащего посредником для доступа к различным ресурсам. Приложение может попросить GAE подписать большой двоичный объект соответствующим закрытым ключом RSA. Полученный токен приложение использует для аутентификации на банковском шлюзе, а тот отвечает идентификатором, который можно употребить для прямого доступа к нужным ресурсам. В данном примере GAE автоматически управляет открытым ключом приложения, а банк получает ключ от хорошо известного поставщика.

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

Лучшие системы делегирования тесно интегрированы с приложением: например, владелец аккаунта Алиса предоставляет аккаунту своего заместителя Боба bob@example.com права на чтение входящих сообщений для Алисы и отправку сообщений с адреса вида «От: Алиса (отправлено bob@example.com)». Механизмы делегирования, интегрированные с приложениями, позволяют обеспечить необходимое взаимодействие без предоставления полного доступа к аккаунту — с помощью соответствующих настроек Алиса доверяет Бобу чтение и отправку электронной почты, но не авторизацию платежей.

Независимое добавление функций делегирования к каждому приложению потребовало бы массы усилий и, вероятно, привело бы к необоснованным различиям между системами. Провайдеры веб-сервисов, искавшие замену порочной практике пользователей передавать свои пароли третьим лицам (например, для просмотра адресных книг), независимо создали целый ряд протоколов, включая Google AuthSub, Yahoo BBAuth и Facebook Login, но сейчас в отрасли наблюдается прогресс в переходе на единый стандарт — OAuth 2.0, который позволяет открыть и при необходимости отозвать ограниченный доступ к аккаунту по SSL-каналу. В качестве возможного усовершенствования в Google предлагают криптографически привязывать токен OAuth к SSL-сеансу.

Существует еще один стандарт аутентификации под названием OATH, который не имеет никакого отношения к OAuth. Базой для OATH являются алгоритмы генерации одноразовых паролей RFC 4226 и 6238, основанные соответственно на хэш-кодах и времени. OATH реализован, например, в приложении Google Authenticator для Android, BlackBerry и iOS. Из-за схожести названий двух стандартов их легко перепутать.

Сервис Google Cloud Print является примером реализации сервисных аккаунтов и делегирования — при печати документа пользователь делится доступом к нему в режиме только для чтения на ограниченный период времени с сервисным аккаунтом, встроенным в принтер с поддержкой печати из облака. Делегирование выполняется с использованием протокола OAuth2. Пользователю не нужно предоставлять принтеру доступ к какой-либо своей личной информации помимо содержания самого документа. И наоборот, принтер (который может находиться в публичном месте) не дает пользователям возможности напрямую связываться с собой или передавать другие полномочия.

***

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

Эрик Гроссе (ehg@google.com) — вице-президент Google по проектированию систем безопасности, Маянк Упадхаяй (mayank@google.com) — главный инженер Google.