Интервью со старшим сертификационным инженером FIDO Alliance о беспарольной аутентификации

Наши пользователи попросили нас реализовать двухфакторную аутентификацию через приложение Google. И недавно мы эту возможность им предоставили. Примерно в то же время консорциум FIDO Alliance опубликовал стандарты для беспарольной аутентификации на сайтах, в мобильных приложениях и веб-сервисах — WebAuthn и CTAP.

Мы заинтересовались этой темой и подготовили материал на Хабре, в котором поговорили о методах, лежащих в основе новых протоколов.

Затем, чтобы прояснить некоторые моменты, касающиеся тонкостей работы стандарта, мы пообщались с Юрием Аккерманном (herrjemand), старшим сертификационным инженером FIDO Alliance. Он ответил на несколько наших вопросов о прошлом, настоящем и будущем аутентификации FIDO. Представляем вашему вниманию текст интервью.


/ Flickr / zhrefch / PD

Расскажите, пожалуйста, о своем бэкграунде и опыте работы в IT-сфере в целом. С чего начинали свою работу в отрасли?

Я занимаюсь программированием с пятнадцати лет. После школы я поступил в университет, где изучал информатику и математику. На втором курсе стал интересоваться криптографией, вопросами ИБ и «наткнулся» на FIDO. Мне очень понравились их протоколы, и в итоге я написал U2F-библиотеку для Python Flask и сделал презентацию.

Мою работу оценили в FIDO. При этом они как раз искали сертификационного инженера. В итоге я стал ответственным за техническую сертификацию.

Как долго вы занимаетесь темами, связанными с аутентификацией в рамках FIDO? Какие задачи вы решали в процессе разработки нового стандарта?

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

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

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

FIDO Alliance основали в 2013 году компании Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal и Validity, которые разработали UAF. Чуть позже к ним присоединились Google, Yubico и NXP — эти работали над предшественником U2F и подумали, что будет выгодно объединить силы, так как их идеи совпадали с идеями Альянса. Они стремились защитить интернет-пользователей от фишинга, решить проблемы удобства использования паролей, а также развивать доступность и безопасность биометрических технологий.

Проводились ли какие-либо предварительные исследования, которые или укрепили намерение создать стандарт, или подтолкнули к его созданию? Если да, то какого рода данные вы анализировали?

Члены альянса, такие как Google, Microsoft, Samsung, Yubico и другие, активно работают над созданием и продвижением стандартов. Они исследуют рынки, пытаясь понять, как FIDO может «вписаться» в различные экосистемы. В Google, например, провели исследование по миграции второго фактора c одноразовых паролей на U2F.

Как родился протокол CTAP? Каким образом он связан с WebAuthn?

FIDO состоит из трех частей: сервера, клиента (браузер) и аутентификатора. Сервер посылает вызов клиенту, клиент передает вызов аутентификатору, который его подписывает и возвращает клиенту, а тот — уже серверу.

Для того чтобы сервер мог пользоваться аутентификацией FIDO, в клиентах есть WebAuthn JS API. С аутентификаторами клиент общается с помощью низкоуровневого протокола CTAP2 (Client-to-Authenticator Protocol 2). CTAP2 описывает CBOR-структуры запросов и транспорты, как, например, USB, NFC и BLE для общения с аутентификатором. Совокупность этих двух стандартов называют FIDO2.

Одной из целей создания формата является защита от фишинга. Какие преимущества стоит выделить по сравнению с другими решениями?

Если говорить о существующих решениях, то единственное, с чем можно сравнить FIDO, это клиентские сертификаты или TLS CCA (Client Certificate Authentication). FIDO и CCA — это фишинг-безопасные вызов-ответ протоколы на публичных ключах. Но у них есть существенные различия.

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

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

У CCA наблюдаются трудности с правильной имплементацией на серверной стороне, так как полная поддержка CCA оставляет желать лучшего. А из-за сложностей работы с TLS, разработчики делают множество ошибок. В FIDO нужна только поддержка самой базисной криптографии. CCA можно реализовывать через HTTP, чего нельзя делать в WebAuthn. Также у CCA проблемы с портативностью и легкостью использования.

Я не считаю, что Альянс изобрел что-то новое. Мы просто разработали хороший протокол, который включает в себя уже существующие механизмы защиты.


/ Flickr / Markus Spiske / PD

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

Один из наших фундаментальных принципов — обеспечение приватности. Биометрическая информация хранится на безопасных чипах и никогда их не покидает. Наши компании работают со считывателями, сертифицированными FIDO или FIPS.

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

Вы как-то говорили, что аутентификация по SMS-коду — это плохой вариант 2FA. Как вы можете это прокомментировать?

SMS-коды или SMS OTP — это двухфакторная аутентификация на одноразовых паролях, доставленных по SMS. Поэтому получается, что это решение уязвимо для фишинга. Если ваш пользователь попался на фишинг и отдал свой логин и пароль, что остановит его от передачи злоумышленникам еще и SMS-кода?

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

Также на сегодняшний день каждый может за 500–600 долларов купить базовую GSM-станцию и перехватить с её помощью SMS, используя MITM-атаку. Ну и, наконец, существуют опасности, связанные с социальной инженерией. Я думаю, многие знакомы с историей, когда злоумышленники похитили солидную сумму денег с банковских счетов, оформив выдачу дубликата сим-карты жертвы. Такое случается в России и других странах с завидной регулярностью.

Как быть, если нужно войти в сервис на нескольких устройствах или одним и тем же сервисом пользуется сразу несколько человек? Поддерживается ли стандартом такой режим работы?

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

А что делать, если токен был утерян? Можно ли будет вернуть доступ к сервисам?

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

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

Самым перспективным решением на сегодняшний день является Delegated Recovery — это рекавери-протокол на основе хранения зашифрованных секретов в других сервисах. Его, кстати, написал один из создателей U2F Братт Хилл (Bratt Hill). Рекавери — это довольно тяжелая и интересная проблема, решение которой нам еще предстоит найти.

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

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

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

Как новый стандарт будет соотноситься с требованиями законов о защите данных (например, GDPR)?

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

И кто уже внедряет стандарт?

Google, Facebook, Dropbox, Salesforce, Bank of America, NTT Docomo… У нас сотни компаний и полмиллиарда ежедневных пользователей. Мы растем с каждым днем. Но все равно, переход на полную беспарольную аутентификацию займет некоторое время.

Как быстро стандарт позволяет осуществить переход с другого метода аутентификации?

Переход с существующих решений двухфакторной аутентификации (например, с OTP) на FIDO довольно прост. Нужно просто подключить библиотеку и реализовать пару изменений на клиентской стороне. В FIDO2 опция для беспарольной аутентификации — это просто дополнительный флаг при регистрации. Перевод же всей экосистемы на полную беспарольную аутентификацию займет некоторое время. Мы прогнозируем, что за 10 лет этот переход совершит 80% всех сервисов.

Какие планы у FIDO по развитию стандарта? Какие улучшения планируется произвести уже в ближайшее время? А в долгосрочной перспективе?

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

Как вы планируете продолжать работу над WebAuthn? Как вам могут помочь участники ИТ-сообщества?

Я, как и раньше, продолжаю свою работу посла в сообществе разработчиков: публикую статьи, тружусь над опенсорсом, делаю презентации, провожу тренинги. Насчет помощи сообщества я могу только сказать: «Нужно больше золота опенсорса».

---

P.S. Юрий Аккерманн также подготовил статью на Хабре, в которой описал основные механизмы безопасности FIDO2 и рассмотрел JS API для работы с ним.