Inadequate Account Lockout in Keystone

Registered by Yan Huang

It is currently not possible to define an account Lockout policy in Openstack/Keystone to lock a user account after a given number of failed login attempts. So this blueprint is to add a configurable policy to lock a user account after a given number of failed login attempts.

Details:
Keystone's SQL Identity backend must support locking out accounts after
some number of invalid login attempts. This is a common feature among
authentication systems and is a common requirement among deployers.

Currently, users (or exploiters) can attempt to authenticate to Keystone
as often as they want with invalid passwords. This is a security problem
because it allows an attacker to use a dictionary of passwords if they
know (or can guess) a username.

Keystone should be configurable so that it rejects any authentication
attempts for a user after some number of invalid login attempts.
Keystone should be configurable so that lockouts do not happen.
The number of invalid login attempts must be configurable.
There needs to be some way to unlock an account that's locked.
There needs to be some way to tell if a user's account is locked or not.
There should be a way to list all locked users.
There should be a way to reset the number of attempts for a user.
Keystone must not provide information to an attacker that the account is
locked or not.
Account lockouts must work when there are multiple Keystone servers (as
in, use the common DB).

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Morgan Fainberg

Related branches

Sprints

Whiteboard

(morganfainberg): This is a larger question on if we plan to support the SQL IDP as a first-class IDP. At this time the answer is "no". This type of functionality should be supported by more feature-rich identity stores by the simple fact that they already do this kind of work. I am marking this as obsolete at this time.

this should be implemented as an optional extension that toggles the user.enabled attribute

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.