Payment Card Industry - Data Security Standard (PCI-DSS) v3.1 provides an industry standard for data security requirements and procedures. Although keystone deals with sensitive data (primarily passwords), it has not made any attempt to provide PCI-compliant tools to deployers for fear of re-implementing more mature identity management solutions. At the same time, deployers are taking on the additional burden of either deploying those fully featured identity management solutions just to support keystone, or are re-implementing these behaviors on top of keystone without community support.
Keystone currently provides no means of satisfying at least the following security hardening guidelines:
Note
There may be additional guidelines that Keystone does not currently satisfy.
Shadow users moved user passwords into their own table, which coincidentally provides a critical stepping stone to implementing all of the above behaviors.
To have the potential to achieve each standard “out of the box”, we at least need to make the following changes and associated behavior:
Note
There may be additional changes required to satisfy the specified guidelines.
Deployers either do not depend on Keystone for these behaviors, and instead back Keystone to an existing identity management solution, or implement these behaviors on top of keystone in middleware.
This spec prevents deployers from having to deploy another identity solution just for PCI compliance, and also prevents multiple operators from duplicating each other’s work any further.
This spec hardens password-based authentication according to PCI-DSS.
None.
Keystone will be capable of presenting a new set of error messages for each new behavior.
Exposing password expirations and last login timestamps is not critical for PCI compliance, so there should be no API impact from this change.
Authentication will require additional checks, although data from tables that are already being read from, so performance impact should be negligible unless the system is being abused.
Several new configuration options will be added to Keystone to customize each behavior. The default values could either reflect Keystone’s current behaviors (and we could simply document the recommended, hardened values), or reflect the recommended PCI-compliant standards in the default values.
None.
None, yet.
Each PCI standard could be pursued independently, but it might be easier to design them all at once, write a single schema migration to add the required columns, and then write individual patches to implement each new behavior over the course of an entire release cycle.
This spec directly depends on the backend refactoring provided by shadow users.
Documentation describing the parts of keystone deployers need to pay attention to when ensuring PCI compliance would be invaluable.