Chrome игнорирует настройку WebAuthentication «userVerification»?

В настоящее время я работаю над потоком аутентификации, основанным на веб-аутентификации. У меня есть устройство yubikey 5 для тестирования.

Для церемонии аутентификации я использую следующие настройки:

  • allowCredentials: [] (пустой массив, так как я хочу использовать обнаруживаемые учетные данные)
  • userVerification: не рекомендуется (в целях минимизации нарушений потока взаимодействия с пользователем)

Я вижу, что при использовании Chrome с этими настройками пользователю всегда запрашивается PIN-код устройства. В Firefox это поведение отличается. В этом случае ПИН-код пользователю не запрашивается.

Это можно легко воспроизвести на этом демонстрационном сайте: https://webauthn.io/

Есть ли у кого-нибудь идеи о том, почему поведение в обоих браузерах разное? Может ли это быть ошибка в Chrome?

Заранее спасибо.

Примечание: тестировалось с версиями:

  • Chrome 123.0.6312.86 (официальная сборка) (64-разрядная версия)
  • Firefox 124.0 (64-разрядная версия)

Я понял, что забыл подумать о реализации MDM API, и она фактически раскрывает некоторые аспекты CredProtect. Таким образом, вы сможете делать то, что хотите, переопределив уровень CredProtect, установленный Chrome. Поскольку Firefox не включает CredProtect в свой запрос, по умолчанию в CTAP он делает то же самое, что и выше, поэтому не должно иметь никакого эффекта. Я соответственно добавил обновление в свой ответ.

Asthor 05.04.2024 16:30
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
В настоящее время производительность загрузки веб-сайта имеет решающее значение не только для удобства пользователей, но и для ранжирования в...
Безумие обратных вызовов в javascript [JS]
Безумие обратных вызовов в javascript [JS]
Здравствуйте! Юный падаван 🚀. Присоединяйся ко мне, чтобы разобраться в одной из самых запутанных концепций, когда вы начинаете изучать мир...
Система управления парковками с использованием HTML, CSS и JavaScript
Система управления парковками с использованием HTML, CSS и JavaScript
Веб-сайт по управлению парковками был создан с использованием HTML, CSS и JavaScript. Это простой сайт, ничего вычурного. Основная цель -...
JavaScript Вопросы с множественным выбором и ответы
JavaScript Вопросы с множественным выбором и ответы
Если вы ищете платформу, которая предоставляет вам бесплатный тест JavaScript MCQ (Multiple Choice Questions With Answers) для оценки ваших знаний,...
2
1
217
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Когда ключи доступа создаются для ключа безопасности в Chrome с UV=required или preferred, они создаются с уровнем credProtect 2, что означает, что при использовании учетных данных требуется проверка пользователя.

В этом случае я предполагаю, что вы создали ключ доступа с помощью UV=discouraged?

Поскольку вы не используете белый список, а для ключа безопасности настроено UV, Chrome, вероятно, принудительно проверяет пользователя, поскольку ключи доступа предназначены для использования в качестве основных учетных данных для входа (например, они не имеют имени пользователя и являются многофакторными). Вы не хотите, чтобы пользователь поднял ключ безопасности с земли и получил полный доступ к чьим-то учетным записям.

Поскольку вы используете это скорее в стиле второго фактора/увеличения, можете ли вы протестировать список разрешенных и посмотреть, запрашивают ли вас все еще UV?

Здравствуйте, спасибо за ваш ответ. Да, я использую UV=discouraged и на церемонии регистрации. Отвечая на ваш вопрос: да. Если я верну список учетных данных, используя свойствоallowCredentials, ПИН-код больше не будет запрашиваться. Но в моем случае я хотел использовать обнаруживаемые учетные данные (оставив параметрallowCredentials пустым), поскольку я заранее не знаю, какой пользователь входит в систему: я хочу реализовать вход без пользователя, чтобы обеспечить быстрый вход в систему (я знаю недостатки безопасности этого подразумевается, но в моем случае возможность обеспечить быстрый вход в систему является основным требованием)

caristu 03.04.2024 16:00

Знаете ли вы какой-либо обходной путь для достижения того же поведения с Chrome, что и Firefox с этой конфигурацией?

caristu 03.04.2024 16:07

Вам нужно будет выполнить поток с приоритетом идентификатора и белым списком, чтобы поддержать ваше требование об отсутствии UV.

Tim 03.04.2024 20:29

Спасибо, но для меня странно, что в зависимости от браузера мне нужно будет реализовать другой поток: в Firefox я могу выполнить вход без пользователя (оставив «белый список» пустым), но не в Chrome...

caristu 04.04.2024 07:50

Chrome фактически отправляет запрос на создание с CredProtect уровня 2, а не 3. Если бы это был уровень 3, вы не смогли бы предоставить ему список разрешений и пропустить проверку пользователя.

Asthor 04.04.2024 17:30

Да, хороший улов. Обновлен исходный пост.

Tim 04.04.2024 21:44
Ответ принят как подходящий

Обновлять

Таким образом, первоначальный ответ верен, и как это работает, но я забыл об одной части, поскольку большая часть того, что я делаю, — это CTAP, а не WebAuthn. Хотя WebAuthn вообще не охватывает CredProtect многого, реализация MDM API делает это через расширения, а точнее credentialProtectionPolicy.

Это позволит вам вручную установить credProtect на уровень 1 по вашему запросу, что позволит вам использовать эти учетные данные для выполнения утверждений без userVerification.

Поскольку вы пометили вопросы с помощью javascript, я предполагаю, что вы делаете это через navigator.credentials.create(options), и тогда запрос должен будет включать

extensions: {
  credentialProtectionPolicy: "userVerificationOptional"
}

Внутри объекта параметров. Затем Chrome учтет уровень CredProtect и установит для него значение 1, а для RK установит значение true при обычном запросе. Это невозможно протестировать на webauthn.io, но вы сможете это сделать с помощью тестовой реализации Auth0

Оригинальный ответ

Есть небольшие различия в том, как Chrome реализовал Webauthn, и в Firefox. Если я создам запрос через Firefox, Webauthn вызовет следующий запрос CTAP

{
  1 => <Buffer 34 9d 9d c8 ef 9a c9 36 b3 3c dd f9 54 aa 57 b4 b1 f0 52 dd c5 7f 86 2e 37 9e ff b4 57 f7 48 57>,
  2 => {
    id: 'webauthn.io',
    name: 'webauthn.io'
  },
  3 => {
    displayName: 'abcde',
    id: <Buffer 58 4c 54 67 73 77 4e 6a 37 34 5f 49 62 4d 75 68 67 47 74 43 5a 4c 6f 67 55 48 50 72 63 4d 49 4c 51 45 72 78 77 73 64 37 35 48 51>,
    name: 'abcde'
  },
  4 => [
    {
      alg: -7,
      type: 'public-key'
    },
    {
      alg: -257,
      type: 'public-key'
    }
  ],
  7 => {
    rk: true
  },
  8 => <Buffer c3 3b a4 9b 74 06 ae e8 76 df 66 a7 57 4e 6b 00 a9 a2 00 e4 ce 40 a4 d4 89 40 06 92 bd a2 80 10>,
  9 => 2
}

Этот запрос, как видно, содержит то, что вы ожидаете: сам запрос имеет rk = true, который позволит обнаружить учетные данные на устройстве. У запроса есть токен, но он влияет только на наше создание, а не на последующее утверждение.

Однако если я сделаю тот же запрос в Chrome, я получу следующий запрос

{
  1 => <Buffer b9 da 62 ad 82 89 4d 87 c8 8c b2 e0 a2 2d 74 23 ef a2 af 04 a9 16 06 76 d6 c4 13 c0 08 04 fa 19>,
  2 => {
    id: 'webauthn.io',
    name: 'webauthn.io'
  },
  3 => {
    displayName: 'Testsetesrsdr',
    id: <Buffer 45 37 4b 4c 76 50 48 59 46 4d 42 7a 5a 5a 75 48 6f 6d 31 4f 65 6f 43 33 68 41 5f 70 44 68 73 57 56 53 45 48 32 41 39 57 71 79 4d>,
    name: 'Testsetesrsdr'
  },
  4 => [
    {
      alg: -7,
      type: 'public-key'
    },
    {
      alg: -257,
      type: 'public-key'
    }
  ],
  6 => {
    credProtect: 2
  },
  7 => {
    rk: true
  },
  8 => <Buffer 1d df 5a dc 36 8b 59 92 95 dd 07 32 c5 8b 1d e8 64 57 c1 e2 b0 67 54 22 b1 7b 50 24 b3 4d 3f 05>,
  9 => 2
}

Почти такая же просьба, rk здесь тоже верна, но есть одно критическое отличие. Chrome добавил к ключу 6 значение credProtect: 2. Уровень CredProtect 2 определен в CTAP как userVerificationOptionalWithCredentialIDList, что означает, что ключ можно будет обнаружить только посредством какой-либо проверки пользователя (в вашем случае — PIN-кода) или путем включения его в список разрешений. Подробнее о CredProtect

Я сильно сомневаюсь, что это ошибка в Chrome, но на самом деле Chrome решил, что это должно быть частью их реализации. Webauthn сам по себе очень мало что делает, чтобы охватить что-либо, касающееся CredProtect, поэтому это решение также не влияет на их соответствие спецификации.

Если это правильный способ сделать это, Chrome становится очень основанным на мнениях, и это не обязательно правильный способ, поскольку предоставление allowList запросам сопряжено с множеством проблем конфиденциальности, многие из которых описаны в webAuthn, особенно в главе 14.6.3.

Итак, если Chrome не изменится, в чем я сомневаюсь, ваш единственный вариант — либо поддерживать и предоставлять allowList, либо проводить церемонию UserVerification. Однако ключ, сгенерированный через Firefox, можно было бы получить и без того, поскольку значение по умолчанию для CredProtect в CTAP равно 1. И его можно было бы получить как в Chrome, так и в Firefox.

Здравствуйте, спасибо за обновление. Я попробовал передать «credentialProtectionPolicy» в функцию navigator.credentials.create, но это не сработало. Похоже, что Chrome игнорирует это, потому что запрос PIN-кода отображается и в этом случае :(

caristu 08.04.2024 08:09

Я также отметил, что когда я также включаю «enforceCredentialProtectionPolicy»: true вместе с «credentialProtectionPolicy: «userVerificationOptional» в часть расширений и устанавливаю «userVerification»: «discouraged», navigator.credentials.create выдает следующую ошибку функция: «NotSupportedError: Запрошенная политика защиты несовместима или несовместима с другими запрошенными параметрами».

caristu 08.04.2024 08:15

@caristu Ого. Удивительный. Ты прав. Chrome фактически создает ключ CredProtect: 1, но выдает ошибку при принудительном применении. Но что я еще заметил, так это то, что Chrome фактически сразу же запрашивает токен у аутентификатора при утверждении, даже с CredProtect: 1. Никакой предварительной проверки или чего-то еще. Хотя я считал тот факт, что Chrome добавил CredProtect: 2 к запросам, когда он не был указан, в лучшем случае спорным, переход сразу к запросам токенов, когда он указан, я бы сказал, что это плохая реализация. Это решительное мнение со стороны Chrome, а не со стороны Chrome, о котором можно высказывать свое мнение.

Asthor 08.04.2024 08:42

еще раз спасибо. К вашему сведению, я сообщил об этом как об ошибке в Chrome: Issues.chromium.org/issues/332580481, учитывая, что Firefox действительно учитывает этот параметр. Пока неясно, считают ли они это ошибкой или нет. ИМХО, похоже, что за включение/отключение проверки пользователя должна отвечать проверяющая сторона, а не браузер.

caristu 08.04.2024 09:54

Другие вопросы по теме