Inadequate Account Lockout in Keystone
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
- Started by
- Completed by
- Morgan Fainberg
Related branches
Related bugs
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