Два шага не обязательно означают два фактора: пароль и PIN относятся к знанию. Биометрия может активировать аутентификатор, но сама по себе не гарантирует анонимность или устойчивость к фишингу.
Сравнивать механизмы, а не экраны
NIST различает знание, владение и биометрические характеристики. Введённый вручную одноразовый код можно ретранслировать через поддельный сайт; SMS и TOTP не равнозначны устойчивой к фишингу аутентификации. Правильно реализованный ключ доступа связывает ответ с сервисом. Гарантии зависят также от локальной проверки, резервирования и синхронизации.
Понимать роль биометрии
В WebAuthn распознавание может выполняться внутри аутентификатора; биометрические данные не передаются принимающему веб-сервису. Локальная проверка может использовать PIN. Присутствие пользователя (UP) и его проверка (UV) различаются. Сервер должен проверять ответ по протоколу; экрана распознавания лица недостаточно.
Защитить жизненный цикл
Предусмотреть регистрацию, добавление метода, потерю устройства, отзыв и восстановление. Оценить доступность и запасные способы, способные ослабить основной вход. Аутентификация не заменяет права на данные и операции.
Источники
Редакционная проверка: 1 ноября 2026 года.
Отделите второй фактор от устойчивости к фишингу.
NIST отмечает, что введенный вручную одноразовый код может передаваться через страницу-мошенник, поэтому само его наличие не делает вход в систему устойчивым к фишингу. Правильно интегрированная WebAuthn связывает ответ с подлинным сервисом. Восстановление учетной записи остается путем обеспечения безопасности.
- Составьте список приложений, все еще принимающих SMS, коды или обходные подтверждения, и отдайте приоритет привилегированным учетным записям.
- Протестируйте регистрацию, потерю устройства и аннулирование на основе реального пользовательского опыта.
- Измерьте охват коэффициента устойчивости и сохраняйте датированные исключения у владельцев.
Первичный источник: NIST SP 800-63B-4. Связанный метод: прочитать практическое руководство.
Passkey: подготовить смену домена и RP ID
Разделить учётную запись, веб-источник и RP ID, чтобы не переназначать данные входа скрытно.
- Запишите старые и новые источники, RP ID и связанные записи. Одинаковое имя записи не делает passkey действительным для другого RP ID. Проверьте допустимые сочетания WebAuthn и доступные пути входа на переходе.
- В разрешённой тестовой среде проверьте challenge, источник, RP ID и связь с записью подходящей библиотекой. Испытайте неожиданный источник и повтор challenge. Смена RP ID требует новой аутентифицированной регистрации: копирование строки не переносит ключ.
- Проверьте пользователя только со старым credential, восстановление и открытые сессии. Задайте открытие и закрытие путей с проверенным возвратом. Регистрация на новом домене не доказывает отзыв всех старых сессий.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}Ожидаемое решение
Вымышленный пример: запись та же, но old.example меняется на new.example с другим RP ID. Старый credential нельзя скрытно перепривязать; новая регистрация проходит предусмотренный аутентифицированный путь.
Можно ли изменить RP ID passkey редактированием базы?
Нет. RP ID входит в проверяемую область credential. Подготовьте допустимую новую регистрацию и аутентифицированную связь записи.
Первичный источник: W3C — Web Authentication Level 2. Связанный метод: прочитать практическое руководство.
postMessage: проверять источник, окно и команду
Задайте контракт сообщений iframe или всплывающего окна, отклоняющий неожиданных отправителей и данные.
- Перечислите точные origin, ожидаемую ссылку на окно и типы сообщений. Для чувствительных данных задайте точный targetOrigin. Origin включает протокол, хост и порт; поиск подстроки в домене не проверяет отправителя.
- Сравните event.origin и для этой интеграции event.source с ожидаемым окном. Проверьте схему, допустимые значения и состояние операции. Обрабатывайте содержимое как данные без eval и вставки HTML. Разрешённый origin не заменяет авторизацию на сервере.
- Испытайте похожий домен, другой порт, другое окно того же origin, неверные поля и сообщения после закрытия. Удаляйте ненужные обработчики и завершайте обмены. Ответы направляйте только на заранее разрешённый origin даже после навигации.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}Ожидаемое решение
Вымышленный пример: https://widget.example разрешён, но event.source — другое окно. Контракт требует активное окно iframe: отклоните сообщение без команды.
Первичный источник: MDN — Window.postMessage. Связанный метод: прочитать практическое руководство.
Идентификация: факторы, сеансы и восстановление
Два фактора: проверять протокол, а не только интерфейс
Вводимые коды, push-подтверждения и ответы WebAuthn по-разному связывают вход с сервисом. Биометрия может активировать аутентификатор, но не заменяет криптографическую проверку ответа.
- Локальная активация — PIN или биометрия в зависимости от устройства.
- Подпись ответа — Ключ сервиса и полученный вызов.
- Проверка сервером — Вызов, источник, подпись и флаги.
- Разрешение действия — Права на объект и операцию.
- Наблюдать UP и UV раздельно.
- Проверять необходимые условия синхронизации и неэкспортируемости.
- Проверять потерю и добавление способа из действующего сеанса.
Подробнее о контроле идентификации →
Источники проверены · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
Расширения: разрешения и доступ
Подробные справочные заметки в этой версии доступны на английском.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent