Центральное место во всех веб-транзакциях занимает процесс борьбы со взломами. Необходимо найти баланс между неудобствами при аутентификации пользователей и риском подделки идентификации. Другими словами, когда знаний об идентификации пользователя достаточно для того, чтобы разрешить выполнение транзакции?
Аутентификация идентификации пользователя уже стала сложной задачей в условиях, когда атаки становятся все более изощренными. Сейчас в самом разгаре процесс масштабного изменения парадигмы. Платформой для большинства транзакций теперь являются портативные устройства, а не настольные компьютеры.
Портативные устройства — причина новых сложностей в защите интернет-сервисов. Из-за неудобных клавиатур с урезанной функциональностью тяжело вводить сложные пароли, поэтому большинство устройств поддерживает функцию запоминания паролей. Кроме того, вероятность потери или кражи портативного устройства гораздо выше, чем настольного компьютера. К тому же, практика показала, что приложения для портативных устройств, в частности, те, которые используют сохраненные пароли, сложно «лечить» от вирусов. Из-за всех этих факторов идентификации пользователей подвергаются дополнительному риску.
Можно посмотреть на распространение портативных устройств под другим углом. Это не такая уж проблема, но если продолжать держаться за решения, основанные на старых методах аутентификации, вы проиграете битву разработчикам злонамеренного ПО и преступникам.
То, что большинство портативных устройств использует специфический канал обмена информацией, а именно, сотовые сети, позволяет вам установить барьер для злонамеренного ПО. Вы можете воспользоваться этим каналом, связав пользователя с определенным телефонным номером. В таком случае, при необходимости можно подтверждать идентификацию пользователя при онлайновых транзакциях, сопоставляя ему определенный набор цифр (или просто проверяя наличие определенной SIM-карты). Результатом будет экспоненциальный рост количества попыток, необходимых злоумышленнику, чтобы взломы были такими же успешными, как и раньше.
Телефонный номер как подтверждение
Использование телефонных номеров, чтобы сократить количество взломов онлайновых ресурсов, — не новая идея. Банки годами используют эту методику. Новинка — то, что эту функцию можно без труда встроить в любой сервис, небольшой или крупный.
Microsoft недавно приобрела PhoneFactor — решение для многофакторной аутентификации, основанное на использовании сотового телефона. Теперь оно доступно для клиентов как Windows Azure Active Authentication. Когда для онлайнового сервиса требуется двухфакторная аутентификация, PhoneFactor предлагает различные варианты реализации второго фактора:
- Сервер автоматически выполняет обратный вызов на телефон с голосовым сообщением, содержащим одноразовый секретный код. Затем пользователь вводит код в веб-форму, чтобы выполнить требуемую онлайновую транзакцию.
- Вместо голосового сообщения также может отправляться SMS сообщение с одноразовым кодом, чтобы убедиться, что пользователь владеет устройством.
- Вариант предыдущего процесса — настроить систему так, чтобы пользователь отвечал непосредственно на SMS (или системе голосового информирования при голосовом вызове). При этом не надо запоминать код при переключении с одного экрана на другой и набирать его на клавиатуре. Вместо этого онлайновый веб-сервис асинхронно уведомляется о получении корректного SMS-ответа от пользователя и запрашиваемая транзакция, ожидающая решения, авторизуется.
- Приложение для сотового телефона, поддерживающее PhoneFactor, принимает запросы механизма аутентификации облачного сервиса и корректно отвечает на них. В отличие от предыдущих вариантов, такой подход требует установки на портативное устройство приложения для смартфонов.
- Вы можете пересылать программный маркер (например, по протоколу OAuth) с компьютера или телефона сервису, использующему утверждения. Сервер PhoneFactor не участвует в пересылке маркера, и ему даже не нужно знать, откуда он пришел.
Принимая во внимание, что большинство пользователей большую часть времени имеет телефон под рукой, все эти способы обеспечивают преимущества многофакторной аутентификации без обычных постоянно растущих расходов на оборудование (маркеры). Такой подход существенно ухудшит кривую «риск/успех» у взломщиков вашего ресурса.
Теперь представьте, что вы хакер, который пытается атаковать веб-сайт, требующий такой тип аутентификации. Объектом атак, как правило является устройство или коммуникационный канал устройства. Атаки на HTTP (TLS)-соединение недостаточно для доступа к веб-сервису, поскольку код авторизации передается на сотовый телефон. Чтобы добиться успеха, хакер должен взломать оба канала.
Новые угрозы
Наряду с тем, от каких угроз избавляет новая технология, хорошо понимать, откуда и когда возникают новые угрозы. К счастью, руткиты (rootkit) еще не стали существенной проблемой в защите сотовых телефонов. PhoneFactor работает на уровне приложений и, следовательно, не защищает угрозы руткитов.
На уровне приложений добавление второго фактора, не имеющего общих коммуникационных каналов с другими факторами, играет существенную роль. Важно обеспечить, чтобы код не был доступен обоим каналам. Значит, пользователь должен в какой-то степени принимать участие — или копировать код из одного процесса в другой, или принимать звонок на телефоне, после чего информация переадресуется одним из описанных выше механизмов.
Любое взаимодействие, не требующее человеческого участия в процессе, подвержено электронной атаке. С другой стороны, новые угрозы одному из каналов аутентификации не более опасны, чем те, которым уже подвергаются статические пароли.
Поскольку код авторизации меняется при каждом обращении пользователя, успешная атака на уровне приложения не позволит злоумышленнику получить неограниченный доступ к веб-сервису. Таким образом, эффективность атак снижается.
Хакеры заинтересованы в получении максимального результата с минимальными затратами, поэтому использование многофакторной аутентификации заставит их поискать более легкую добычу где-то еще. Благодаря такие сервисам как PhoneFactor реализация многофакторной аутентификации становится относительно недорогой и вероятность успешной атаки сокращается.
На коробках с игрушками часто пишут предупреждение: «требуется сборка». Это относится и к PhoneFactor. Чтобы помочь вам разобраться в типичных требованиях к интеграции, в оставшейся части статьи я расскажу, как применить PhoneFactor в двух сценариях взаимодействия с пользователем.
Вход на веб-сайт
В случае входа на веб-сайт, с которым работает пользователь, наша цель — задействовать PhoneFactor для надежной аутентификации. Тогда можно представить идентификацию пользователя в стандартном формате веб-маркеров (Web token). Можно задействовать PhoneFactor в сценариях аутентификации на веб-сайте через браузер, откладывая принятие решения по запросу до тех пор, пока сервис не свяжется с пользователем по телефону. После того как пользователь пройдет аутентификацию, веб-страница актуализируется и пользователь получает возможность выполнять свои ценные транзакции.
Чтобы это работало, веб-приложение должно доверять аутентификацию пользователя сервису PhoneFactor. Также оно должно в каком-то виде возвращать идентификацию пользователя или другие атрибуты пользователя. Всегда, когда это возможно, при разработке веб-приложений следует использовать стандартные форматы маркеров, такие как Security Assertion Markup Language (SAML) или JSON Web Token (JWT). Тогда приложения будут более способными к взаимодействию.
PhoneFactor и Active Directory
Однако PhoneFactor — это не только средство аутентификации для веб-сайтов. Он также делает аутентификацию более безопасной при входе в настольные компьютеры с Windows, не причиняя особых неудобств. Microsoft долго осознавала то, что необходимо поддерживать альтернативные методы аутентификации в Windows.
Credential Provider API поддерживает такую расширяемость. Чтобы начать процесс, пользователь скачивает провайдер удостоверений (Credential Provider, CP) на устройство. Когда пользователь пытается войти, CP отправляет сообщение службе аутентификации, запрашивая звонок или SMS от PhoneFactor. CP показывает окно редактирования, в которое пользователь должен ввести код, полученный по телефону.
После проверки кода серверная система аутентификации выполняет еще одну операцию — выпуск для пользователя сертификата инфраструктуры открытых ключей (public key infrastructure, PKI), действующего в течение короткого периода. CP использует этот сертификат для входа по протоколу Kerberos. В качестве дополнительного уровня защиты у вас может быть сертификат закрытого ключа, связанный с защитным чипом Type Parameter Model (TPM) на клиентском устройстве. Также он может связываться со случайным PIN, генерируемым CP. В результате мы получаем многофакторное удостоверение, которое нельзя экспортировать и которое может взаимодействовать с существующими приложениями и оборудованием.
Преимуществом такого подхода является то, что ликвидируется разрыв между PhoneFactor — новым режимом аутентификации — и существующей инфраструктурой Active Directory. Имеется несколько компонентов, участвующих в двухфакторной аутентификации компьютеров с Windows:
- Пользователь входит с существующим доменным паролем, к которому добавляется секретный код, генерируемый PhoneFactor. В этой модели используется доверяемый веб-сервис, управляющий взаимодействием между клиентом и серверными компонентами PhoneFactor.
- CP получает сертификат от центра сертификации (Certificate Authority, CA) и входит в Windows Active Directory. Доверяемый веб-сервис использует SAML-маркер от Active Directory Federation Services (AD FS), чтобы получить сертификат для входа по протоколу Kerberos/PKINIT.
В этом сценарии пользователю приходится вводить PIN на компьютере, присоединенном к домену, но можно установить на телефон приложение, позволяющее пользователю подтверждать запрос на телефоне одним нажатием.
Преимущества двухфакторной аутентификации общеизвестны, но их было сложно добиться на практике, поскольку за них приходится платить передачей второго фактора в руки пользователей. Имеется несколько способов распространить новую технологию Microsoft — PhoneFactor — в «мирах» интерактивного входа в интрасети и входа на веб-сайты, поддерживающие стандарты аутентификации.