Перевод Кластер критической децентрализации 36c3 - Почему ваш проект должен поддерживать FIDO2 и WebAuthn

Тема в разделе "Журналы о Monero", создана пользователем Mr. Pickles, 27 июл 2021.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    995
    Симпатии:
    249

    Аннтотация

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


    Стенограмма выступления

    Диего: Итак, вы пришли на эту презентацию и говорите мне: «Диего, пора тебе покинуть сцену», и я буду счастлив сделать это. Я передаю микрофон Яну, который расскажет нам о WebAuthn. WebAuthn, друзья мои, не мешало бы добавить сюда гласных. Но я не буду спрашивать, почему вы этого не сделали. Начинай и расскажи нам о том, что это такое.

    Ян: Хорошо, спасибо. Я буду говорить о паролях и новых способах сетевой аутентификации. Но сначала позвольте представиться. Меня зовут Ян, я основатель Nitrokey. Мы занимаемся созданием открытого аппаратного обеспечения в Германии. Прежде всего, мы занимаемся разработкой и производством ключей защиты памяти, предназначенных для шифрования данных, или криптографических ключей, таких как HSM, а также, конечно, занимаемся проблемами двухфакторной аутентификации и беспарольной аутентификации, о которой я буду говорить сегодня. Но сначала мне хотелось бы показать вам эту картинку — так выглядят устройства, которые мы разрабатываем, чтобы вы понимали, о чём пойдёт речь. Это USB-устройства, ключи защиты памяти, подобные этому, но это не совсем обычные устройства.

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

    Тому есть несколько причин. Все мы знаем, что они по природе своей небезопасны. По крайней мере, их сложно сделать безопасными. Поэтому ими просто пользоваться, но делать это небезопасно. Скажем, можно без труда запомнить один пароль для пары сервисов, но это уже будет небезопасно. И что же делать, чтобы повысить уровень безопасности? Можно придумать более длинную фразу-пароль для каждого сервиса, такую фразу, которую вы уже не сможете запомнить, если вы пользуетесь, допустим, десятком сервисов. Поэтому вам для этого понадобится некоторый способ, менеджер паролей или что-то в этом роде. Таким образом, всё довольно быстро усложнится.

    Это никак нельзя масштабировать, и, кроме того, в этом случае отсутствует какая-либо защита от фишинга. Но эта проблема решаема, если задействовать более современные методы, такие как WebAuthn, о котором я буду говорить чуть позже. И мне бы хотелось напомнить ещё об одной вещи — удобство. Обычно когда речь заходит о безопасности, о том, чтобы сделать что-то безопаснее, то подразумевается компромисс с точки зрения удобства использования. То есть, как правило, вопрос ставится следующим образом: вам нужно нечто более безопасное или удобное в использовании? И в данном случае, как мне кажется, мы достигли той точки, в 2019 году мы достигли точки, когда мы можем создать решение, которое будет более безопасным и более простым в использовании, чем когда-либо ранее. И я считаю, что в долгосрочной перспективе это решение будет очень эффективным и во многом будет способствовать развитию.

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

    Также существовал и существует метод FIDO Universal 2nd Factor, более известный как FIDO U2F. Это метод двухфакторной аутентификации, дополняющий ваш пароль, который может использоваться сервисами и приложениями вместе с обычным именем пользователя и паролем. Это своего рода современные одноразовые пароли, которые более просты в использовании и поддерживаются большинством современных браузеров. У них более современная криптографическая инфраструктура, не предусматривающая наличия общего секрета между клиентом и сервером, но в большей степени использующая криптографию публичных ключей, что на сегодняшний день является обычным делом. И в данном случае преимущество заключается в защите от фишинга. Я кратко расскажу, как это работает. И ещё одна вещь, о которой многие не знают, это некоторая форма защиты анонимности. Спецификация изначально предусматривает невозможность отслеживания вас как пользователя определённого сайтом среди множества других сайтов, поскольку конкретная личность просто отсутствует, а вместо неё для каждого веб-сайта создаётся криптографический ключ или криптографическая личность со стороны клиента, а следовательно, её нельзя отследить при посещении множества других сайтов. Как правило, это не является обязательным требованием спецификации, но большинство вариантов реализации, насколько мне известно, используют эту возможность, и со стороны клиента количество памяти не является фиксированным, но существует механизм динамического выведения этих ключей. Когда я говорю о таких ключах, я имею в виду специфический ключ клиента, который выводится контекстно, а следовательно, вы можете использовать его с неограниченным количеством веб-сайтов или аккаунтов. Как я уже сказал, механизм поддерживается большинством браузеров, но до этого момента это было проприетарным расширением, и ситуация меняется с появлением WebAuthn. Но раньше расширение было проприетарным, и поэтому в том виде его поддерживало не так много браузеров. Тем не менее практичность решения была на высоком уровне, так как оно поддерживалось браузерами, браузерам был известен этот механизм, и для пользователя предусматривались специальные окна и запросы, такие как: «Подключить ваше устройство FIDO U2F?» или «Нажмите эту кнопку», или другие подобные вещи. Поэтому пользователям не приходилось использовать какое-либо дополнительное программное обеспечение.

    Теперь о том, как это работает. Я не буду вдаваться в подробности. Даже несмотря на то, что, вероятно, вам не очень хорошо видно, это верхний уровень, это схема верхнего уровня, которую мы используем для всех других механизмов FIDO, о которых я буду говорить. Итак, справа показан сервер. У нас есть указка? Вот сервер, который отправляет запрос, есть браузер и есть устройство FIDO, скажем, защитный ключ FIDO, защитный ключ USB, защитный ключ Bluetooth. Итак, сервер отправляет… прошу прощения, здесь мы ещё находимся в процессе регистрации. Это начальная регистрация пользователя, который хотел бы добавить устройство FIDO U2F к своему аккаунту. Это пока не процедура аутентификации. Итак, сервер отправляет клиенту запрос и собственный ID, который называется «абсолютным адресом», который можно рассматривать в качестве доменного имени, и он отправляет его браузеру. Браузер проверяет этот абсолютный адрес или ID приложения, что, по сути, и является защитой от фишинга. Если ID приложения не совпадает с доменным именем определённого сайта, браузер отклоняет запрос. Таким образом, он проверяет, чтобы доменное имя соответствовало ID приложения. Затем этот запрос передаётся защитному USB ключу, защитному ключу FIDO, а пользователь, чтобы подтвердить его, как правило, должен нажать на устройство, и это будет означать подтверждение запроса, то есть что он хочет зарегистрироваться. Устройство, веб-сайт, генерирует специфическую для аккаунта пару криптографических ключей, пару ключей на эллиптической кривой, на основе пары параметров создаёт подпись и отправляет это обратно — отправляет обратно публичный ключ, соответствующую ключам подпись, а также подтверждающий ключ, чтобы сервер мог проверить, соответствует ли ответ запросу, и привязать эти ключи к аккаунту пользователя. А затем, во время аутентификации, всё происходит схожим образом: сервер отправляет запрос и ID приложения, а также ключи, которые были привязаны к аккаунту пользователя ранее в процессе регистрации. И схема работает схожим образом: подтверждение со стороны пользователя, извлечение или выведение ключей и подписи, которые отправляются обратно серверу, чтобы он снова мог произвести верификацию. Сервер видит, что ответ соответствует запросу, также он проверяет соответствие результатов вычисления, и происходит аутентификация пользователя.

    Таким образом, всё относительно просто. А этот FIDO2 — довольно новый стандарт. В этом году, по-моему, вышла версия 1.0. Можно считать, что это FIDO U2F, то есть снова двухфакторная аутентификация. Она используется в дополнении к имени пользователя и паролю. И FIDO2 — это то же самое, что и FIDO U2F, но с парой отличий. Прежде всего, это беспарольная аутентификация. И здесь всё становится интереснее, поскольку вы как разработчик сетевых приложений при использовании беспарольной аутентификации можете заменить имя пользователя и пароль, но, прежде всего, уйти от использования паролей. Таким образом, пользователю не придётся запоминать какой-то определённый пароль к своему аккаунту на вашем веб-сайте. Вместо этого ему надо будет запомнить пин-код к устройству, и когда я говорю об устройстве, я имею в виду устройство FIDO, и этот пин-код будет уникальным для устройства и никак не будет зависеть от конкретного веб-сайта. Таким образом, вы запоминаете один пин-код вместо сотни паролей, и он будет коротким, а не какой-то длинной фразой-паролем. Аутентификация без использования имени пользователя подобна беспарольной аутентификации, но отличие состоит в том, что имя пользователя выдаётся сервером, поэтому пользователю даже не приходится вводить имя пользователя для аутентификации, а достаточно просто воспользоваться своим устройством FIDO, а имя пользователя при этом будет передано серверу.

    Теоретически этот метод можно использовать с различными типами устройств: защитным USB ключом, например, TPM или биометрическим устройством, внешним устройством, другими вариантами, реализующими этот стандарт FIDO2. Прежде всего, он был написан для сетевых приложений. Но совсем не обязательно может использоваться только с ними. Он также может использоваться с локальными приложениями. Его практичность огромна, и мы поговорим об этом позже. На данный момент метод не так распространён. Мне известно, что Microsoft пользуется им в своих сетевых сервисах, а также для локальной аутентификации в Windows 10. Но метод хорош, поскольку людям более нет необходимости запоминать пароль, чтобы войти в локальный компьютер, а достаточно воспользоваться устройством FIDO или FIDO2. И мне неизвестно, использует ли какой-либо сайт или сервис этот метод, кроме Microsoft, на данный момент, но, думаю, скоро всё изменится.

    Теперь что касается WebAuthn или сетевой аутентификации. Мы используем обозначение WebAuthn для краткости. Данный график позволит лучше понять, что это такое. У нас есть сервер и браузер, и спецификация сетевой аутентификации определяет API со стороны браузера, которым вы будете пользоваться как разработчик сетевого приложения. В основе WebAuthn лежат FIDO и FIDO2, которые здесь мы обозначили как CTAP1 и CTAP2, и это протокол, который используется между браузером и, скажем, защитным USB ключом или встроенным в ноутбук TPM, и тогда всё решается посредством WebAuthn. И спецификация появилась не в этом 2019 году, это уже реализовано во многих браузерах, даже в последней версии Far, которая вышла несколько недель или несколько месяцев назад.

    И как это работает. Прежде всего, давайте посмотрим, сколько времени осталось. Опять же, я не стану углубляться в детали, но даже так видно, что схема похожа на схему FIDO2 с некоторыми, разумеется, изменениями. Прежде всего, изменена вся терминология: более мы не говорим о сервере, а называем это «доверительной стороной», которой может являться локальное приложение. Также мы называем защитный USB ключ или другое устройство «аутентификатором», как правило, это клиент, веб-браузер. В случае с запросом появляется больше опций. Доверительная сторона или сервер могут указать определённые параметры, которые им необходимо получить при аутентификации. Вся прелесть в том, что сервер сам, в зависимости от случая, решает, что ему нужно: возможно, отпечаток пальца, вводимый через устройство, или же, если вы заходите в чувствительную с точки зрения безопасности область сайта, второй логин, какая-нибудь биометрическая верификация или что-то в этом роде. То есть сервер может запросить, что ему нужно, даже после первичной верификации, установив эти параметры. Таким образом, с точки зрения регистрации это вновь означает, что пользователь хочет связать своё устройство FIDO2 со своим аккаунтом. И снова пара параметров обеспечивает защиту от фишинга браузером, который верифицирует доверительную сторону относительно абсолютного адреса. В данном случае мы используем вычислитель хешей, а затем идут подтверждение пользователем и верификация. Это звучит практически так же, но на практике имеются отличия — подтверждение обычно означает нажатие кнопки, если пользователь хочет подтвердить выполнение этой операции. Но в случае с WebAuthn верификация означает нечто иное. Она означает, что пользователь действительно использует то, о чём заявляет, и в зависимости от устройства FIDO2 верификация обеспечивается различными механизмами — это может быть ввод пин-кода устройства, о чём я уже упоминал, это могут быть биометрические данные, такие как отпечаток пальца, позволяющие подтвердить, что пользователь действительно является пользователем, владеющим, допустим, устройством FIDO2. Затем вновь генерируется пара криптографических ключей, вычисляется подпись, и ответ отправляется обратно доверительной стороне, которая производит верификацию. И фактическая процедура аутентификации, по сути, выглядит схожим образом. В данном случае второй фактор относится к механизму FIDO U2F, а первый — к беспарольной аутентификации. По сути, не только первый фактор — паролем является первый и второй фактор. Но вся схема во многом похожа, и вся разница состоит только в параметрах. Поэтому я всё объединил в один слайд. Доверительная сторона отправляет запрос, имя самой доверительной стороны, браузер снова обеспечивает защиту от фишинга, проверяя абсолютный адрес доверительной стороны, или же некоторые пользовательские данные или параметры, необходимые для верификации пользователя, и аутентификатор снова делает то, что требуется для аутентификации, допустим, требует нажатия кнопки или ввода пин-кода, после чего ответ отправляется обратно доверительной стороне, которая производит верификацию по паре колючей, которые были привязаны к аккаунту пользователя при выполнении предыдущего шага, на этапе регистрации.

    Что касается аутентификации без имени пользователя, основная разница находится здесь, со стороны клиента, скажем, браузера. Браузер обеспечивает пользовательский интерфейс, некое окно, где пользователь может выбрать личность, которую он хочет использовать для аутентификации на определённом сайте. Таким образом, да, здесь используется имя пользователя, но уже не на самом сайте, а только со стороны клиента, так как это родное окно браузера. По-моему, сейчас эта возможность поддерживается только Google Chrome, но я не уверен — это одна из самых продвинутых возможностей WebAuthn. Ранее я сказал, что все основные браузеры поддерживают WebAuthn, что действительно так, но, думаю, наиболее продвинутые возможности поддерживаются не всеми. Надеюсь, что ситуация изменится. Затем пользователь выбирает ID, который он хочет использовать для аутентификации на этом конкретном сайте, а затем реализуется та же схема, что была описана ранее. В данном случае сетевая служба или доверительная сторона, конечно, также получает имя пользователя, но именно то имя, которое пользователь выбрал здесь.

    Теперь о том, что следует использовать. Это обобщающий слайд, последний или предпоследний, так что, возможно, у нас останется минута на вопросы. Я думаю, что аутентификация с использованием пароля подходит для простых проектов, не особо ориентированных на обеспечение безопасности. Мне кажется, мы увидим сдвиг всей экосистемы, всё больше и больше сайтов и приложений будут переходить к использованию WebAuthn и подобных механизмов аутентификации, то есть требования пользователей к веб-сайтам будут смещаться в направлении аутентификации на основе WebAuthn, обеспечивающей безопасность критически важных с точки зрения пользователей веб-сайтов. Поэтому я более не рекомендовал бы использовать OTP. Возможно, в некоторых случаях этого было бы достаточно, но я бы не рекомендовал использовать OTP в новых проектах. Вместо OTP лучше использовать WebAuthn или двухфакторную аутентификацию, FIDO U2F, или беспарольную аутентификацию, о которой я говорил, или даже аутентификацию без использования имени. Но это потребует больше работы с точки зрения реализации. Некоторые библиотеки, совсем немного, можно найти на GitHub или где-нибудь в сети Internet, и вы сможете использовать их в зависимости от выбранного вами языка программирования, но их совсем немного. Так что, реализуя эти методы, вы будете в некотором роде пионерами. Кроме того, занимаясь беспарольной аутентификацией, убедитесь в том, что ваш браузер или браузер, который выбрал ваш пользователь или заказчик, действительно поддерживает это.

    Здесь приводится пара ссылок. Первая будет очень полезна для тех, кто использует OTP. Кроме того, по ней можно найти обзор пары сотен популярных и не очень популярных веб-сайтов, а также описание механизмов, поддерживаемых этими сайтами, то есть таких механизмов, как OTP или WebAuthn / FIDO. Это может стать хорошей отправной точкой, если вы как пользователь решите выбрать для себя безопасный механизм аутентификации. Другая ссылка в большей степени предназначена для разработчиков, которым интересна сама спецификация. Или же, перед тем как разбираться со спецификацией, вы можете почитать этого парня, опубликовавшего пару хороших вводных статей, или же посетить блог, посвящённый WebAuthn.

    На этом у меня всё. У нас осталось время на вопросы? Думаю, это означает, что осталось. Итак, ваши вопросы?

    Вопрос из зала: Привет. Спасибо за выступление. Как проверить правильность относительно доменного имени, как происходит процесс валидации?

    Ян: Процесс реализуется браузером. Если вы разработчик, то вам вообще не стоит беспокоиться об этом. То есть следует понимать, как происходит валидация, необходимо знать, читается поддомен или нет, и подобные вещи, но самим делать ничего не нужно. Это готовое решение. Необходимо только наличие HTTP, но FIDO и WebAuthn не будут работать просто с HTTP, а что касается поддоменов, то думаю, есть более хорошее визуальное объяснение, можно найти таблицы с примерами, которые доступнее, чем я здесь объясню всё это. Пройдите по ссылкам, и вы найдёте их.

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

    Ян: Информацию по устройствам, поддерживающим FIDO2 в целом, можно найти здесь. Прежде всего, это наше устройство FIDO2 Nitrokey. Также есть Solokey, другой открытый проект, YubiKey — сильный конкурент, и ещё пара других. Кажется, тут был следующий вопрос. Вы следующий?

    Вопрос из зала: Я следующий. Недавно я разработал доказательство концепции для своей компании, и я был очень удивлён тем, что Safari на MacOS пропускает пин, необходимый для беспарольной аутентификации. Пин реализуется аппаратным обеспечением или браузером?

    Ян: Браузером. Браузер должен напоминать пользователю о необходимости ввода пина.

    Вопрос из зала: Я смог отредактировать YubiKey через Chrome, используя пин. А затем я использовал Safari, и Safari мог получить доступ к ключу без пина, просто взяв первый из множества, но не смог выбрать нужный. И я был удивлён этим.

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

    Вопрос из зала: Ответ от браузера к серверу проходит, если был введён пин?

    Ян: На данный момент я уверен, что да. Эта информация предоставляется в ответе, чтобы сервер мог верифицировать её. Сервер не должен доверять посредническому браузеру или делать что-то подобное. Нет.

    Вопрос из зала: Значит, это ошибка Safari.

    Вопрос из зала: Вопрос, касающийся бизнес-решений. Поддерживают ли данные методы в полной мере бизнес-среду, где используются тонкие клиенты или небольшие устройства, которые удалённо подсоединяются к сервисам, то есть FIDO2 или подобные решения — есть ли здесь какие-нибудь ограничения?

    Ян: Под бизнес-средой вы имеете в виду Windows, например? Насколько мне известно, в случае с Windows, как я уже говорил ранее, когда речь идёт об инструментах аутентификации на локальной машине Windows, требуется, например, Azure Active Directory. Это пока не работает с локальной активной директорией, что является большим ограничением. Я надеюсь, что Microsoft скоро добавят эту возможность для локальной активной директории в другой среде, бизнес-среде, но пока мне неизвестно о готовом решении, поддерживающим это.

    Вопрос из зала: Мой вопрос в меньшей степени касался аутентификации в Windows или на удалённом сервере, а, скорее, касался перехода к удалённой сессии. То есть я подключаю свой защитный ключ FIDO2 к своему устройству, а затем могу пользоваться им на сервере через окно браузера, например?

    Ян: Вам нужен способ получить доступ к клиентской сессии через USB устройство.

    Вопрос из зала: Это обычное USB устройство, а не какое-то особое, вроде смарт-карты или чего-то подобного?

    Ян: Всё правильно, обычное устройство, обычное USB устройство класса USB HID, для взаимодействия с человеком: мышь, клавиатура относятся к такому классу USB устройств, классу, используемому по умолчанию.

    Вопрос из зала: Окей, спасибо.

    Ян: Если вы имеете в виду VM или Syncline, вам может понадобиться зайти через USB устройство, но для FIDO не понадобится никакого специального драйвера. Последний вопрос? Oкей, кажется, время закончилось. Возможно, вы найдёте меня где-нибудь здесь. Спасибо.

    ---

    Источник: Critical Decentralisation Cluster 36c3 - Why Your Project Should Support Passwordless Login, FIDO2, WebAuthn

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.