WebAuthn Беспарольная аутентификация в Joomla 4. Часто задаваемые вопросы (FAQ) и дополнительная информация.

Информация о материале: Родительская категория: CMS — движки сайтов; Категория: Joomla 4

Нет кнопки входа в систему "Веб-аутентификация"
Имя пользователя все еще нужно указать. Разве WebAuthn не должен избавиться от имен пользователей?
После регистрации аутентификатора, при попытке войти в систему выдается сообщение о том, что регистрация не была выполнена. Это ошибка?
В Safari нет запроса на использование системы аутентификации
При попытке использовать WebAuthn в Safari появляется странное сообщение об ожидании запроса
Не удается использовать биометрический датчик (TouchID, отпечаток пальца, Windows Hello)
При использовании программного аутентификатора зачем нужен аппаратный токен?
Почему учетные данные зашифрованы в базе данных? Не является ли это излишеством?
Настроена двухфакторная аутентификация, но вход в систему осуществляется без предоставления секретного ключа. Не является ли это небезопасным?
Разве TFA не достаточно хорош? Зачем нужен WebAuthn?

Нет кнопки входа в систему "Веб-аутентификация".

Не обеспечивается доступ к сайту по протоколу HTTPS. WebAuthn доступен только для сайтов HTTPS с действующим сертификатом. Это мера предосторожности, встроенная в стандарт WebAuthn. Плагин фактически проверяет, есть ли доступ к сайту через HTTPS, используя Uri (бывший класс JUri). В редких случаях, когда сервер лжет о протоколе, кнопки может не быть, даже если сайт (утверждает, что он HTTPS). Однако если SSL не сообщает вашему веб-серверу, что доступ к сайту осуществляется через HTTPS, то у вас серьезные проблемы с безопасностью, связанные с cookies, и их нужно решать, а не жаловаться на то, что данный сервис не отображает кнопку WebAuthn.

Обратите внимание, что модули входа сторонних разработчиков и компоненты, реализующие собственную форму входа, пока не будут отображать эти кнопки. Для их поддержки была добавлена новая инфраструктура, подобно тому, что пришлось сделать в Joomla 3.2 для поддержки двухфакторной аутентификации.

Имя пользователя все еще нужно указать. Разве WebAuthn не должен избавиться от имен пользователей?

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

После регистрации аутентификатора, при попытке войти в систему выдается сообщение о том, что регистрация не была выполнена. Это ошибка?.

Это ошибка, но не с самим плагином.

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

Перейдите в бэкэнд вашего сайта, Система (System), Общие настройки (Global Configuration) и установите для параметра Сообщения об ошибках (Error Reporting) значение Нет (None). В большинстве случаев для неправильно работающих плагинов ядра и 3PD этого достаточно. В противном случае изучите вывод запроса с помощью инструментов разработчика вашего браузера, чтобы выяснить, что именно вызывает ошибку в запросе.

В Safari нет запроса на использование системы аутентификации.

Этого больше не должно происходить в iOS 13, iPadOS 13 и macOS Catalina.

Это ошибка Safari в старых версиях Safari. В более старых версиях Safari поддержка WebAuthn была только экспериментальной и не совсем законченной. В ходе тестирования она также работала только с аппаратными USB-ключами (FIDO и FIDO 2).

При попытке использовать WebAuthn в Safari появляется странное сообщение об ожидании запроса.

Этого больше не должно происходить в iOS 13, iPadOS 13 и macOS Catalina.

Это еще одна ошибка в старых версиях Safari. Закройте браузер (CMD-Q) и перезапустите его. В большинстве случаев это сработает. Если было зарегистрировано более одного аутентификатора, он все равно не будет работать должным образом.

Не удается использовать биометрический датчик (TouchID, отпечаток пальца, Windows Hello).

Только Google Chrome на ограниченном числе платформ корректно поддерживает встроенные аутентификаторы с биометрической защитой. Браузеры на базе Chrome, такие как Opera или Brave, спросят пользователя, нужно ли использовать встроенный датчик, но при выборе этой опции произойдет сбой. Другие браузеры, такие как Firefox и Safari, даже не предлагают такой возможности. Это ограничение браузеров, и его нельзя обойти.

Если используется ОС Windows, помните, что ваше устройство ДОЛЖНО иметь чип Trusted Platform Module (TPM) и он должен быть включен в BIOS. Просто наличие биометрического датчика, совместимого с Windows Hello, не поможет. Это мера предосторожности, предусмотренная самим стандартом WebAuthn: информация аутентификатора должна обрабатываться с помощью безопасного, устойчивого к взлому оборудования для предотвращения подмены ключа (например, вредоносное ПО, запущенное на компьютере, не сможет украсть ключ, используемый для аутентификации).

Также, пожалуйста, помните, что WebAuthn - это все еще очень новый стандарт. К тому времени, когда выйдет Joomla 4, браузеры продвинутся достаточно далеко, чтобы сделать WebAuthn более удобным для обычного пользователя. В настоящее время мы находимся на переднем рубеже развития безопасных логинов.

При использовании программного аутентификатора зачем нужен аппаратный токен?

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

В случае аппаратного аутентификатора, будь то отдельное аппаратное устройство или TPM / Secure Enclave, это является само собой разумеющимся в силу самой природы аутентификатора.

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

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

Учитывая, что цена ключа FIDO, совместимого с WebAuthn, на Amazon составляет менее 10 евро, в большинстве практических случаев достаточно использовать аппаратный аутентификатор.

Почему учетные данные зашифрованы в базе данных? Не является ли это излишеством?

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

Однако, если бы злоумышленник имел доступ на запись только к таблице базы данных #__webauthn_credentials, без доступа на чтение к файловой системе и без доступа на запись к любой другой таблице, он мог бы вставить свой собственный аутентификатор, выдавая себя за целевого пользователя в системе. Это очень теоретическая атака, так как в этом случае необходимо знать логин пользователя, которого атакуют. Кроме того, наличие доступа на запись только к этой таблице, а не ко всей базе данных (в этом случае можно было бы создать нового суперпользователя), крайне маловероятно. Тем не менее, чтобы сделать невозможным даже такую теоретическую атаку, учетные данные шифруются.

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

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

Нет, это сделано намеренно и с умыслом.

Когда в Joomla 3.2 появилась двухфакторная аутентификация (TFA), вход на сайт можно было осуществить только с помощью имени пользователя и пароля. Пароли могут быть украдены или угаданы. Поэтому TFA была единственным способом обеспечить хоть какую-то степень безопасности для объектов с высоким риском и высокой стоимостью. Это было в 2013 году, семь лет назад.

WebAuthn - это совершенно другой зверь. Она использует сильную криптографию и безопасное оборудование, чтобы сделать практически невозможным подмену криптографических ключей аутентификации (до сих пор ни у кого нет доказанной способности скомпрометировать аппаратные ключи безопасности и доверенные аппаратные модули, как объяснялось выше). Кроме того, WebAuthn не поддается подделке, т.е. невозможно обмануть систему, используя ее на сайте, выдавая себя за другого пользователя, поскольку учетные данные WebAuthn привязаны именно к тому доменному имени, для которого они были выпущены (да, если для работы сайта используется несколько доменов или сайт переносится на другой домен, нужно будет перерегистрировать все аутентификаторы WebAuthn - это именно так!) Таким образом, аутентификация с помощью WebAuthn невероятно безопасна и превзошла те требования, которые были предъявлены к TFA. Поэтому, если проверка подлинности с помощью WebAuthn прошла успешно, секретный ключ TFA проверять не нужно - и поэтому он вообще не проверяется.

Для обеспечения максимальной безопасности следует использовать как WebAuthn, так и TFA на аккаунте. WebAuthn - это дополнительный способ входа в Joomla, а не единственный. Аутентификация по паролю по-прежнему разрешена и не может быть отключена ни глобально, ни для каждого аккаунта (по крайней мере, пока). Поэтому кто-то все еще может угадать или украсть пароль так же, как это было в 2013 году, когда в Joomla появился TFA. TFA защитит авторизацию пароля. WebAuthn позволяет обойтись без пароля для повседневного использования, что делает гораздо менее вероятным кражу пароля.

Разве TFA не достаточно хорош? Зачем нужен WebAuthn?

Сам по себе TFA достаточно хорош в большинстве случаев, но страдает от двух проблем.

Во-первых, у него довольно неудобный пользовательский интерфейс. Требуется предоставить постоянно меняющийся секретный ключ вместе с именем пользователя и паролем. Большинство пользователей используют TOTP (шестизначный PIN-код, который меняется каждые 30 секунд), что замедляет вход в систему и обычно раздражает пользователей. Использование YubiKey намного быстрее, но также дороже и сложнее в обеспечении. В режиме YubiKey-OTP срок службы ключа также составляет около 2 лет при ежедневном использовании (у него заканчивается память, которую он использует для записи и отслеживания выданных им подписей).

Во-вторых, если используется TOTP, безопасность подвержена таким проблемам, как кейлоггеры, фишинг и возможность кражи секретного ключа, используемого для генерации TOTP. Более того, имея миллион возможностей и тридцать секунд на их опробование, можно предположить, что злоумышленнику может повезти, поскольку Joomla не блокирует ваш аккаунт и не использует ограничение скорости за неудачные попытки входа. Хотя эти средства защиты могут быть реализованы, сама реализация может быть использована для создания ситуации отказа в обслуживании, которая блокирует законного пользователя на его сайте, пока злоумышленник занят проникновением на него. Это тот случай, когда лекарство хуже болезни.

WebAuthn значительно улучшает удобство работы пользователей. За неполный год с момента первого внедрения (март 2019 года) до настоящего времени (февраль 2020 года) браузеры приняли WebAuthn и предлагают привлекательный интерфейс, направляя пользователей к эффективному использованию аутентификаторов. Вход в систему с помощью WebAuthn кажется более удобным, чем даже использование функции автоматического заполнения паролей в доверенном менеджере паролей. Взаимодействие все еще немного неудобно на мобильных устройствах, но и это быстро меняется.

В чем WebAuthn действительно поражает, так это в безопасности. Благодаря использованию безопасного оборудования и надежной проверке доменного имени сайта он практически неуязвим для кейлоггеров, фишинга и подмены ключей. В нем даже есть встроенная защита от клонирования ключей. Да, можно потерять оборудование или его могут украсть, но то же самое происходит и с ключами от дома. По крайней мере, отменить аутентификатор WebAuthn гораздо проще, чем сменить замки (вы когда-нибудь теряли ключ от машины или, что еще хуже, ключ-карту?).

«WebAuthn в Joomla 4. Беспарольный вход в систему»

Перевод с английского официальной документации разработчиков Joomla 4:
https://github.com/joomla/joomla-cms/pull/28094

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)