Source: keystone Version: 2:27.0.0-3+deb13u5 Severity: important Tags: patch security X-Debbugs-Cc: Debian Security Team <[email protected]>
As per launchpad bug at: https://bugs.launchpad.net/keystone/+bug/2158970 POST /v3/users/{user_id}/password (change password) is decorated @unenforced_api and requires only the user's original_password to succeed. When a user has MFA rules configured (e.g. requiring TOTP), this endpoint does not verify the additional factor. This violates the security guarantee MFA is intended to provide: a user who enables TOTP does so specifically because they expect their account to remain safe even if their password is stolen. For every other operation — login, API access, token issuance — that guarantee holds. For change_password it does not. Attack scenario: Precondition: victim has TOTP MFA rules configured. Attacker has obtained the victim's password (phishing, credential breach, etc.) but does not have access to the TOTP device. 1. Attacker cannot log in — TOTP gate blocks them. MFA is working as intended. 2. Attacker calls POST /v3/users/{user_id}/password with the stolen password, sets a new password the victim does not know. No token required (@unenforced_api), no TOTP required. 3. Victim's password is now unknown to them. They cannot log in. Their TOTP device is now useless — there is no second factor without the first. 4. Recovery requires admin intervention (PATCH /v3/users/{user_id} with admin token to reset the password). Root cause: identity.core.change_password calls only self.authenticate(user_id, original_password), a pure password check. MFA rules registered for the user are not consulted. There is no mechanism to require additional factors for this endpoint even when the user's account policy mandates them. Specification references: I was quick to dismiss this as a "hardening opportunity" when initially discussing this in bug 2157347 , but I was ignorant that the industry consensus is clear in this regard: • OWASP MFA Cheat Sheet: explicitly lists "Changing passwords" as a sensitive action for which MFA should be required alongside login • OWASP ASVS 7.5.1: "Verify that the application requires re-authentication before allowing modifications to sensitive account attributes which may affect authentication" • CWE-306: Missing Authentication for Critical Function • CWE-304: Missing Critical Step in Authentication: "The software implements an authentication technique, but it skips a crucial step that weakens the authentication." Suggested fix: Before executing the password change, check whether the user has active MFA rules. If so, require those factors to be satisfied — either via a valid session token that was issued meeting those factors, or by accepting the MFA factors inline in the same request body. A documented recovery path (admin-assisted password reset) should be provided for users who have lost their MFA device, replacing the current implicit bypass. Related: bug 2157347 (TOTP single-use not enforced — companion issue in the same MFA subsystem) Affected versions: All Keystone releases supporting per-user MFA rules, Stein (15.0.0) onwards.
