Keystone isn't acting on consecutive failed logins

Bug #963098 reported by Ionuț Arțăriși
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Opinion
Wishlist
Rafael Durán Castañeda

Bug Description

Trying to login to the dashboard web interface and failing causes no special action no matter how many times it's attempted.

Malicious users could abuse this in order to try to guess logins and passwords.

This could be prevented by a delay or a capcha after the first few failed login attempts.

Tags: blueprint
Revision history for this message
Devin Carlen (devcamcar) wrote :

What you describe is piece of a larger issue. Even if we put these measures in place in Horizon, it would do nothing to prevent someone from using command line tools to accomplish the same end. I'll reword this case to reflect that.

summary: - dashboard isn't acting on consecutive failed logins
+ Keystone isn't acting on consecutive failed logins
no longer affects: horizon
Joseph Heck (heckj)
Changed in keystone:
status: New → Triaged
importance: Undecided → High
Joseph Heck (heckj)
Changed in keystone:
milestone: none → folsom-1
tags: added: blueprint
Revision history for this message
Nag (srirangamn) wrote :

Hi,

Any blueprint prepared for this functionality?

Revision history for this message
Joseph Heck (heckj) wrote :

nope - probably not going to lay out most of the blueprints until the summit, although I may get some nailed down prior to then. If you want to do this work, please feel free to start a blueprint and link it up to this bug, and attack!

Revision history for this message
Nag (srirangamn) wrote :

Hi Joseph,

Thanks for the info.

Actually I want to give a try on this bug in the following way:

1. User types the wrong password for 5 times.
2. Then dashboard need to show the security question for the particular user. [Security question will be shown if user enters correct username. Otherwise wrong username or password error should be displayed.]
3. If the user types the wrong security question's password, the account should be locked and admin only can unlock the account.
4. If the user enters correct answer for the security question, the new password shall be mailed to his email id, if he registers one.

The security question and answer fields can be added to the users table or can be a separate table in the keystone.

This is fine as far as the dashboard is concerned. But as per the comments from Devin, I am thinking about blocking the user from command line arguments.

Please provide your comments.

Regards,
Nag.

Revision history for this message
Rajesh Battala (rajesh-battala) wrote : RE: [Bug 963098] Re: Keystone isn't acting on consecutive failed logins

Hi Nag,

What if the hacker, who is aware of username and tries to access the account.
As he enters wrong password for 5 times, security question will be shown.
And security questions also will be given wrong answer. Then the account is locked.

But once the actual user tries to access the a/c with proper credentials then he will get message that his a/c is locked by admin. Which would be a surprise for the actual user.

Thanks
Rajesh Battala

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Nag
Sent: Wednesday, April 04, 2012 4:15 PM
To: Rajesh Battala
Subject: [Bug 963098] Re: Keystone isn't acting on consecutive failed logins

Hi Joseph,

Thanks for the info.

Actually I want to give a try on this bug in the following way:

1. User types the wrong password for 5 times.
2. Then dashboard need to show the security question for the particular user. [Security question will be shown if user enters correct username. Otherwise wrong username or password error should be displayed.] 3. If the user types the wrong security question's password, the account should be locked and admin only can unlock the account.
4. If the user enters correct answer for the security question, the new password shall be mailed to his email id, if he registers one.

The security question and answer fields can be added to the users table or can be a separate table in the keystone.

This is fine as far as the dashboard is concerned. But as per the comments from Devin, I am thinking about blocking the user from command line arguments.

Please provide your comments.

Regards,
Nag.

--
You received this bug notification because you are subscribed to Keystone.
https://bugs.launchpad.net/bugs/963098

Title:
  Keystone isn't acting on consecutive failed logins

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Trying to login to the dashboard web interface and failing causes no
  special action no matter how many times it's attempted.

  Malicious users could abuse this in order to try to guess logins and
  passwords.

  This could be prevented by a delay or a capcha after the first few
  failed login attempts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/963098/+subscriptions

Revision history for this message
Joseph Heck (heckj) wrote :

Nag - not a bad idea, but one that we need to be a touch cautious around. In some implementations of Keystone, the keystone system itself *will not* have access to lock a password or otherwise manipulate the ID system. Keystone is going to be acting as a facade in many deployments, not the end system in itself - and some backends will not support any manipulation of user credentials externally.

Additionally, Rajesh's comment is fairly reasonable about the user experience - a flow like that is totally valid, but if we implemented it we need to make sure that the user could receive some useful notification that their credentials have been locked for security reasons and provide a means for them to get them unlocked. Otherwise we've enabled another security flaw in a denial of service to the system users.

Revision history for this message
Jeff Ward (lo-jeff-h6-deactivatedaccount) wrote :

Some OpenStack users will have specific, stringent, and organizationally-defined requirements for any controls that preform account lockout, while other organizations will be more concerned with a DoS of user access (things like this: http://capec.mitre.org/data/definitions/2.html).

From my view, there are a lot of different user account management requirements between organizations, and building features into keystone to support different requirements may not be tremendously valuable. A lot of authentication products support this type of functionality in a highly configurable way, and a lot of organizations have tools in place to facilitate these controls. By focusing on providing an interface between keystone and in-place authentication tools we allow the in-place processes and solutions to apply to OpenStack resources without requiring change.

With these thoughts in mind, I would posit that account lockout and re-enabling is an organization-wide authentication process / control and not necessarily an OpenStack-specific control, so I imagine in a lot of deployments this will be left to the back-end identity provider for many OpenStack users.

With all that said, it most certainly makes sense to me to build some functionality within keystone that implement basic account lockout for users who aren't backending keystone with another tool; but exploring a robust set of features in for account lockout may not be necessary.

One last thought: it strikes me that for any account lockout features built in to keystone we may want to consider automatically disabling any of these features when a backend authentication provider is configured to avoid troubleshooting confusion in the event of an account being disabled.

Revision history for this message
Nag (srirangamn) wrote :

Hi Rajesh and Joseph,

Thanks for your comments. We can display a nice message to the user regarding blocking the user logging into dashboard.
Please let me know if there is any other alternative to check the user authentication.

@Jeff,

The locking mechanism will be only at Keystone end because most of the organizations may provide only read-only access to their authentication systems. In that case, we cannot lock the user in the back-end systems.

The idea is, if keystone is integrated with an organization's authentication system with read-only access, the user shall be blocked at Keystone level. As we cannot block the user in the back end authentication system as it is read-only.

Please let me know your comments on the same.

Regards,
Nag.

Revision history for this message
Thomas Biege (thomas-suse-deactivatedaccount) wrote :

For our products I do not recommend having the functionality of locking user accounts because it bites back at you (easy denial of service, locked admin account, ...). I prefer increasing delays per client and a security warning for the admin, clearly logged somewhere. Such a log message should not contain the username entered by the client, but a user ID to avoid injection attacks and leaking of password that were accidently entered as username. The delay and the logging could be done by keystone (configurable) without patching the front-end (except for connection timeouts < login delays)

BTW, https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

Revision history for this message
Rafael Durán Castañeda (rafadurancastaneda) wrote :

Hi,

Any advance about this at design summit? I've been thinking about how to solve this:
* Adding a "Security" middleware saving information about "suspicious" requests (e.g.: 4xx-5xx)
* Allow a pluggable set of "actions" based on that information. I think kesytone can't provide something that just works for everyone, since this can be quite different for every organization, and thus the most important thing is each one can easily add custom "actions".
* Provide some generic actions as example e.g.: mail to sys admins, increase delay,..
* Migrating the ratelimit middleware from Nova probably would help a lot on this

What do you think??

Joseph Heck (heckj)
Changed in keystone:
assignee: nobody → Rafael Durán Castañeda (rafadurancastaneda)
Revision history for this message
Rafael Durán Castañeda (rafadurancastaneda) wrote :

Blueprint added and next keystone meeting will be discussed.

 https://blueprints.launchpad.net/keystone/+spec/improve-keystone-security

Revision history for this message
Thierry Carrez (ttx) wrote :

Closing the bug, will be tracked in blueprint.

Changed in keystone:
importance: High → Wishlist
milestone: folsom-1 → none
status: Triaged → Opinion
Revision history for this message
Ionuț Arțăriși (mapleoin) wrote :

I've adapted the nova_limits turnstile middleware to keystone which can be used to solve this problem. The code is available on github. See this mailing list email for more information on the keystone_limits project: https://lists.launchpad.net/openstack/msg16630.html

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.