PCI-DSS Password Requirements API¶
Part of the PCI-DSS work included enforcing password strength requirements. These requirements are kept within keystone, but they should be discoverable so other services can advertise and leverage them.
Released with Newton was the ability to enforce specific requirements on password strength for local keystone users. Keystone uses these requirements to check passwords for new and existing users, which works fine in a stand-alone model. However, when a user is interfacing with horizon the experience can be suboptimal for the two following reasons:
If a user’s password fails the requirements, horizon has no way of describing the requirements to the user. Typical password systems will tell a user the requirements needed, otherwise the user is left guessing random password combinations. This is the most important use case if PCI-DSS is going to be used effectively in an OpenStack deployment.
Client libraries have no way of knowing the password requirements enforced by keystone (including Horizon, OSC, python-keystoneclient bindings, etc). The regular expression that enforces the password requirements is only used within keystone. By letting other services, like horizon, discover the regular expression, they can perform quick password validation before issuing the password request to keystone.
We can make the password requirements and the description of the requirements
discoverable via the API. This can be done by leveraging the existing domain
The changes necessary would be to make
a whitelisted section of the domain configuration API. The change would need
to make the API read-only for those values. The following would be an example
of using the domain configuration API to get the password requirements:
GET /v3/domains/default/config/security_compliance/password_regex GET /v3/domains/default/config/security_compliance/password_regex_description
In order to ensure password strength requirements can be fetched by all users, it could be isolated into its own API, using its own routers, controllers, etc.
If PCI-DSS password checking isn’t
enabled, then a
404 Not Found will be returned, implying there are no
requirements to enforce since it’s not in configuration.
One alternative is to create a dedicated API for returning the password
requirements as they are known in the
keystone.conf. This would be a much
simpler API, but it wouldn’t be leveraging any of the domain configuration API
at all. This might be a useful option depending on how invasive it is to
whitelist PCI-DSS password configuration. If PCI-DSS support is available per
domain in the future, this would have to be reworked.
A second alternative would be to expose the variables to horizon through a copied version of keystone’s configuration file. This option would require horizon and keystone to have the same requirements at all times. If the two sources of information are out of sync, user experience will be terrible because horizon will be advertising the wrong requirements or checking against outdated requirements.
If we implement this through the existing domain configuration API, there are some security concerns around the policy for domain configuration. This change would require keystone to loosen the policy for domain configuration so that it can be usable for all users, not just admins. If the policy isn’t loosened, the implementation of the specification using domain configuration would only be useful to administrators, or users with the admin role. Another security concern we need to be aware of with this approach is making sure password requirements can’t be modified through the API. Allowing password requirement changes to an entire domain, or deployment, over the API would be a security concern if not handled at the deployer or administrator level.
If we isolate returning password requirement information to its own API, we can build a policy for it that doesn’t interfere with existing policy. This would be an advantage of the first alternative listed above.
Regardless, the API for requesting password requirement information needs to be protected. If password information isn’t protected, it would be easy for a potential attacker to obtain the password requirements for a deployment and tailor an attack using those requirements.
Other End User Impact¶
This will make it easier for end users to use horizon to manage their passwords in a PCI-DSS enabled deployment.
Keystone password management APIs might require an additional call to get the password requirements. This isn’t a major performance concern since the call to get password requirements is extremely lightweight and passwords typically don’t change often.
Other Deployer Impact¶
This change would not require any additional work for deployers. Once a deployer enables PCI-DSS, the password requirement information can be retrieved from the API. If the information is changed by the deployer, the new requirements will be retrievable via the API.
This change will require a follow-on specification or patch for horizon to consume the change.
- Primary assignee:
Lance Bragstad <firstname.lastname@example.org>
- Other contributors:
Propose a patch to the domain configuration API to allow looking ups for the default configuration file,
Propose a patch to whitelist
keystone.conf [security_compliance] password_regexand
keystone.conf [security_compliance] password_regex_descriptionretrieval using the domain configuration API.
Update policy to allow fetching of password strength requirements
Test to make sure password requirements cannot be modified through the domain configuration API.
Add developer information to keystone PCI-DSS documentation
The documentation impact will be relatively minimal, as it’s a single API call.