Вопрос или проблема
Здесь новичок в сфере безопасности. Я пытаюсь создать механизм безопасного входа без пароля для своей веб-службы.
Механизмы аутентификации
Моя идея заключается в том, чтобы призвать пользователей использовать следующие два метода входа:
- WebAuthn с токеном FIDO2 (желательно с биометрической безопасностью, например, с VeriMark Guard или YubiKey. Современные смартфоны также предлагают функции Face-ID и датчики отпечатков пальцев)
- Аутентификация с использованием публичного ключа как SSH/GPG. Пользователям нужно только иметь свой резервный публичный ключ где-то, возможно, также опубликованный на сервере ключей. В то время как частный ключ хранится на зашифрованном устройстве или другом аппаратном токене в другом географическом местоположении.
WebAuthn очень полезен для регистрации и входа в систему на ежедневной основе, но в случае потери или повреждения он не работает.
Я ищу существующие лучшие практики в этой области, регламенты или просто примеры, которые делали что-то подобное раньше.
В GitHub и GitLab, например, можно клонировать репозитории с помощью аутентификации SSH, но не входить на сайты.
Почему это, по-видимому, никогда не возможно?
Почему наиболее заметная процедура восстановления состоит в том, чтобы ввести (обычно довольно короткий) код восстановления, например, “2957174”. Это даже менее безопасно, чем иметь пароль?
И да, я понимаю, что не у всех есть доступ к необходимому оборудованию, поэтому вход с паролем все равно должен быть возможен.
Прежде всего, WebAuthn является аутентификацией с использованием публичного ключа. Полное название спецификации W3C WebAuthn – “Веб-аутентификация: API для доступа к учетным данным публичного ключа”. Другим вариантом аутентификации с использованием публичного ключа в браузере является взаимный TLS, где и сервер, и клиент представляют сертификат и подтверждают право собственности на соответствующий частный ключ, подписывая хэш сообщений рукопожатия TLS. Браузеры не поддерживают протокол OpenSSH или OpenPGP на нативном уровне. Это можно сделать с помощью JavaScript или расширений браузера, но вы должны иметь очень вескую причину для использования сторонней реализации вместо одной из нативных решений.
Что касается процедур восстановления для WebAuthn: стандартным решением является регистрация нескольких аутентификаторов. Если один из них потерян или поврежден, пользователь может переключиться на другой. Было предложение интегрировать надлежащую процедуру резервного копирования в протокол WebAuthn, но, насколько я знаю, это все еще на экспериментальной стадии. Таким образом, на практике решение состоит в том, чтобы либо требовать дополнительный аутентификатор, либо применять совершенно отдельную процедуру резервного копирования. Например, вы можете предложить длинный случайный код, который пользователи могут (безопасно) хранить для восстановления после сбоя аутентификатора.
Обратите внимание, что короткие коды Google заменяют только второй фактор в аутентификации 2FA, и я достаточно уверен, что аккаунт быстро будет заблокирован, если Google обнаружит несколько неудачных попыток.
Ответ или решение
Лучшие практики сброса WebAuthn FIDO2
Введение
В условиях современного цифрового мира вопрос безопасности является основополагающим аспектом разрабатываемых веб-сервисов. Системы, основанные на WebAuthn и FIDO2, обеспечивают надежную альтернативу паролям, используя публичные и приватные ключи для аутентификации пользователей. Однако, как и любая другая технология, эти механизмы требуют надлежащей реализации стратегии сброса, чтобы эффективно справиться с потерей или повреждением аутентификаторов.
Основные принципы WebAuthn и FIDO2
WebAuthn, часть спецификации W3C, является API, предназначенным для доступа к публичным ключевым учетным данным. Аутентификация с помощью FIDO2 позволяет пользователям использовать биометрические данные, USB-токены и другие устройства для безопасного входа. Однако следует помнить, что при утрате устройства пользователю потребуется альтернатива для восстановления доступа.
Лучшие практики сброса для WebAuthn
-
Регистрация нескольких аутентификаторов
- Рекомендуется предусмотреть возможность регистрации нескольких аутентификаторов для одного пользователя. Это может быть сделано путем подключения разных устройств (например, основной и резервный токены), чтобы в случае потери или повреждения одного из них, пользователь всегда имел доступ к другому.
-
Процедура восстановления
- Разработка четкой стратегии восстановления является ключевым фактором. В качестве альтернативы пользователю можно предложить сгенерированный длинный случайный код, который должен храниться в защищенном месте. Это позволит ему восстановить доступ в случае потери аутентификатора.
- Важно отметить, что такой код не должен быть слишком коротким, поскольку это делает систему более уязвимой для злоумышленников.
-
Дополнительные методы аутентификации
- В случае потери аутентификатора можно предусмотреть различные методы многофакторной аутентификации, например, отправка одноразового кода на зарегистрированный номер телефона или электронную почту. Это может служить дополнительным уровнем безопасности при восстановлении доступа.
-
Обучение пользователей
- Обучение пользователей значения защиты их аутентификаторов и важности использования резервных токенов может значительно снизить уровень потерь. Рекомендуется включить в интерфейс ясные инструкции и предупреждения о правах и обязанностях пользователей.
-
Стандартизация процедур
- Использование стандартных протоколов и рекомендаций по сбросу аутентификаторов, таких как предложения, выдвинутые для расширения WebAuthn, позволит обеспечить лучшую интеграцию с существующими системами и уменьшить риск внедрения уязвимостей.
Разъяснение существующих практик
Хотя некоторые платформы, такие как GitHub и GitLab, предлагают аутентификацию через SSH, интеграция с веб-аутентификацией, как правило, ограничена из-за недостаточной поддержки браузерами и отсутствия надлежащей реализации протоколов. Это подчеркивает необходимость использования хорошо разработанных и протестированных решений.
Заключение
На этапе внедрения механизма аутентификации без паролей через WebAuthn и FIDO2 крайне важно обратить внимание на меры предосторожности и стратегии сброса аутентификаторов. Четко продуманные процедуры, возможность регистрации нескольких аутентификаторов и обучение пользователей помогут минимизировать риски и обеспечить безопасность веб-сервиса. Сохраняя ориентацию на безопасность и удобство, вы создадите надежную и безопасную среду для ваших пользователей.