Authelia — это сервер аутентификации и авторизации с открытым исходным кодом, обеспечивающий двухфакторную аутентификацию и единый вход (SSO) для приложений через веб-портал. Если пользователям разрешен вход в систему через имя пользователя и адрес электронной почты, система регулирования рассматривает их как отдельные события входа в систему. Это приводит к тому, что ограничения регулирования фактически удваиваются, если предположить, что злоумышленник использует грубую силу для подбора пароля пользователя.
Важно отметить, что из-за эффективной работы регулирования, при которой ни по времени, ни по ответам API не видны никакие признаки запрета, обращенные к пользователю, фактически невозможно определить, произошел ли сбой из-за неправильной комбинации имени пользователя и пароля или из-за эффективного запрета, блокирующего попытку, что значительно снижает любую форму грубой силы. Это происходит потому, что в процессе записи и подсчета в этой системе используется метод, используемый для входа, а не эффективный атрибут имени пользователя. Это оказывает минимальное влияние на безопасность учетной записи, это влияние естественным образом увеличивается в сценариях, когда двухфакторная аутентификация не требуется и используются слабые пароли.
Это немного упрощает подбор пароля. Исправление этой проблемы было применено к версиям 4.38.19 и 4.39.0. Пользователям рекомендуется обновиться.
Пользователи, которые не могут выполнить обновление, должны: 1. Не изменять настройки по умолчанию таким образом, чтобы это приводило к более коротким или менее частым банам. Настройки по умолчанию эффективно снижают вероятность использования этой проблемы. и 2.
Отключить для пользователей возможность входа в систему через адрес электронной почты.
Показать оригинальное описание (EN)
Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It's important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it's effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This makes it a bit easier to brute-force a password. A patch for this issue has been applied to versions 4.38.19, and 4.39.0. Users are advised to upgrade. Users unable to upgrade should 1. Not heavily modify the default settings in a way that ends up with shorter or less frequent regulation bans. The default settings effectively mitigate any potential for this issue to be exploited. and 2. Disable the ability for users to login via an email address.
Характеристики атаки
Последствия
Строка CVSS v4.0