[Security:low] psessions case sensitivity might impact security of 2FA when using case-insensitive auth backends
When using a case-insensitive login backend (LDAP), the psession key is by default computed from the
_user variable (through
_whatToTrace), which may be uppercase or lowercase depending what the user typed into the login form.
This can lead to a situation where an attacker can register their own 2F device, unbeknownst to the legitimate user.
Configure the following:
- LDAP authentication backend
- TOTP enabled, self registration enabled
- Require 2FA enabled
Then, login as
- On first login, you are required to setup a TOTP device
- Login again, you are now protected by the TOTP device
Everything is going well so far
- Login as
- You are now asked to setup another TOTP device
You may now login as either
MYUSER, each one will use a different TOTP device. But what if the
MYUSER TOTP device was setup by a malicious user using stolen credentials? Applications might in many cases still identify
MYUSER as exactly the same account as
myuser depending what attributes are being transmitted.
LDAP backend is vulnerable to this, maybe others...
The attack described here only affects "trust on first login" scenarios, where trust in a 2F device is automatically granted the first time a user logs in.
There is no need to upgrade to mitigate this issue on existing platforms, simply normalize the case of
_whatToTrace and you won't be affected anymore.
_whatToTrace=lc($_user) or perhaps simply
Since LDAP is probably our most common user backend, perhaps we should use
_whatToTrace by default.
Or perhaps case insensitive backend could normalize
_user themselves to make sure situations like the one described above cannot happen?