Handle one time password and very large passwords #33110
Conversation
This adds an option to disable storing passwords in the database. This might be desirable when using single use token as passwords or very large passwords. Signed-off-by: Carl Schwan <[email protected]>
For passwords bigger than 250 characters, use a bigger key since the performance impact is minor (around one second to encrypt the password). For passwords bigger than 470 characters, give up earlier and throw exeception recommanding admin to either enable the previously enabled configuration or use smaller passwords. Signed-off-by: Carl Schwan <[email protected]>
Signed-off-by: Carl Schwan <[email protected]>
CarlSchwan
requested review from
ArtificialOwl,
blizzz and
come-nc
and removed request for
a team
CarlSchwan
added
the
pending documentation
|
About the second commit: explanation? Does it just take too long? On the third commit: should not this be dependent on the introduced setting? Otherwise, is it not backend-dependent? |
Yes it takes 30 seconds to then login if we have a 8192 key. Probably best to abort.
IHMO big passwords with 400 characters shouldn't be allowed as it created a tradeoff and the security argument is not valid since even 100 characters are big enough that it is uncrackable. With the DB backend, we can ensure that the user won't shoot itself in the foot, with the other backends we need to handle the case there the user already shoot itself in the foot. Generally, though so big passwords are actually no passwords but just one-time token generated by the authentication provider. |
blizzz
added
4. to release
|
@CarlSchwan did you test with LDAP ? as far as I remember there's logic that periodically pings the LDAP server with the user's password to check if the user was disabled on LDAP side. and if the auth fails, the user gets disabled. now if the password is not stored, that logic should fail gracefully |
3 seperate commits, see description of the individual commits