Comment 43 for bug 1688137

I spent two days examining source code, why users are not receiving explanation about locking account and finally I found this thread. I'm operating various systems (AD, linuxes, LDAPs), where users have feedback from system, why the logon not works in case of failure. I can't see proper explenation why keystone developers loose balance between usability and security. Of course account locked information is some kind of leak of information about account names, but this is overkill for authentication usability. If something wrong is happening with locking acocunts, the administrator should take necessary steps to investigate and prevent the attack. The logs should be analyzed continously to prevent the attacks, but HOW TO DO IT IF THERE ARE NO LOGS!!!
Please consider once again such useless security standards. There is no security if administrator and user has no information about logon failures! After spending a lot of time on those problems I realized that I have no tools to monitor failure logons and locking accounts. Even no account names appearing keystone in logs. This is not what administrator is expecting from secure authentication system!

My comments to the argumentation above:

>So just to summarize, this report covers three possible vulnerabilities related to the PCI-DSS account lock out feature:

>1. If someone can guess a username they can prevent that user from authenticating by repeatedly attempting to log in with an >incorrect credential.

Yes this is kind of problem, but the attacker can guess the user name in other ways and making such attack. In such cases the user should reported abuse and then the openstack operator should prevent such attacks by blocking IP address or changing account name. These issues shouldn't be handled automatically but obscurity, but every case should be investigated and prevented.

>2. Someone can identify valid usernames by trying to log in with candidate strings with invalid passwords until the lock out is >reached, at which point the change in API response confirms the existence of that user.

> 3. The lock out response can be used as an oracle to determine the UUID matching any known or guessed username.

These problems occur on every authentication systems. But lockout threshold should prevent such attacks using for example throttling policies. Another way: log lockout events to keystone log only (now there are no information, even when insecure_debug is on).

I think that administrator should have possibility to choose the security level of keystone authentication process, depending on company needs and company security policy.