[Security:low] psessions case sensitivity might impact security of 2FA when using case-insensitive auth backends
Concerned version
Version: %2.0
Summary
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.
Vulnerable scenario
Configure the following:
- LDAP authentication backend
- TOTP enabled, self registration enabled
- Require 2FA enabled
Then, login as myuser
- 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
MYUSERwithmyuser's password - You are now asked to setup another TOTP device
You may now login as either myuser or 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.
Backends used
LDAP backend is vulnerable to this, maybe others...
Mitigations
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.
Example: _whatToTrace=lc($_user) or perhaps simply _whatToTrace=$uid
Possible fixes
Since LDAP is probably our most common user backend, perhaps we should use lc($_user) in _whatToTrace by default.
Or perhaps case insensitive backend could normalize _user themselves to make sure situations like the one described above cannot happen?