It’s time for sensible password security standards in the PCI-DSS

LOCKEDPasswords are the keys to the Internet kingdom.  Sure, there are certificates that identify sites and provide the basis for TLS encryption, but it is the user ID and password that authenticate you almost everywhere you log on to something.  The implication is that the service you log on to must have a way to validate that the password you provide today matches the one you provided when you signed up or at your last password change.  But many network sites and services fail to protect those passwords properly and that significantly compounds the damage in the event of a breach.  To mitigate the potential damage, the PCI Data Security Standard (PCI-DSS) requires passwords to be encrypted.  Although this sounds good on its face, the standard fails to account for the bi-lateral nature of passwords.  As a result, assessments are more complex and expensive and the systems assessed often less secure because of it, not more.  The changes I propose would decrease the cost of compliance while improving the level of security.Let me pause here to say that I fully support the principles of the PCI-DSS.  Without a standard to require it, security is one of the places where companies seek to minimize costs because it does not directly contribute to the functionality users pay for.  If any one company skimps on security, they gain an efficiency and profit advantage that pressures their competitors to also cut corners.  The existence of a mandatory baseline helps prevent this spiral to the bottom.  However, the mitigations required by such a standard must seek to maximize effectiveness with the least possible burden of compliance.  The standard must be capable of changing when it becomes clear that it does not meet these goals.  This is one such case.

I should also mention that these are my observations based on interactions with many customers and not necessarily the official position of IBM.

I refer specifically to PCI-DSS requirement 8.4 “Render all passwords unreadable during transmission and storage on all system components using strong cryptography.”  The problem with this is that it doesn’t distinguish between the two types of password, each of which have very different security requirements.  However because under the PCI-DSS a password is a password, QSA’s and implementers often treat them all equally.  In the few cases where the different types of password are treated according to their unique requirements, the customer has no assurance of passing subsequent assessments unscathed since the next assessment may interpret the standard differently.

The primary use case for passwords, and the one that the PCI-DSS appears to address, is the one I outlined in the first paragraph: that of a networked service to which users log on.  Best practices are to encrypt the account password with many iterations of a one-way salted hash, storing the resulting value.  Subsequent login attempts transform the password presented in the login request using the same algorithm and then compare the result to the stored value.  This is the classic case of encrypting stored passwords.  Note that there is no requirement in this use case for the stored password to ever be rendered in plaintext.  I will refer to this use case as an inbound authentication request because the thing storing the passwords is receiving an access request.

The second use case for passwords is where an application makes an outbound access request of something else.  Typical examples are when an application authenticates to a remote LDAP server or requests a connection to a JMS message broker.  In this use case, the application presenting the ID and password must render them in plaintext in order to make the access request.    I will refer to this use case as an outbound authentication request because the thing storing the passwords is requesting access to something else.

Note that in the inbound access request use case the stored password must never be rendered in plaintext, while in the outbound access request use case the stored password must always be rendered in plaintext.  If your intuition tells you that these two use cases differ greatly in their security requirements, and that attempting to treat them the same would result in poor security, then your intuition would be correct.  However the wording of the PCI-DSS fails to differentiate between the two use cases and customers frequently report that their QSA has specified remediations that are complex, expensive, and either fail to improve security or actually make it worse.  The justification in these cases is that “the PCI-DSS requires it.”

Because the PCI-DSS does not distinguish between these two use cases for passwords, the mitigations specified fail to address either case adequately and lumps them all together as a requirement for “encryption.”  In addition to treating the outbound side as a seperate use case, the standard should refine the use case on the inbound side to specify non-reversible encryption, perhaps borrowing from OWASP.

I propose that the standard distinguish between passwords for inbound access requests versus those for outbound access requests.  The current best practices of salted, hashed passwords using strong, one-way encryption would be associated with inbound requests.  There hasn’t been a discussion on how best to secure passwords for outbound requests since we have not, as yet, seen fit to talk about them separately.  That discussion should take place as soon as possible in order to arrive at a consensus and codify that into the standard.

In order to facilitate that discussion,  consider a JEE server that is started when its host reboots.  The JEE server then requests a connection to a database using an ID and password.  Although the database stores a hashed version of the password, the JEE server must render it in plaintext in order to present it to the database.  Usually the JEE server retrieves its ID and password from the filesystem, either in an ini file, in a keystore, in boot scripts or in some other location.  Sometimes that file, or perhaps just the password in the file, is encrypted.  In that case, how does the JEE server render it into plaintext?  A secondary password is required and it, too, must be stored somewhere.  In order to comply with the standard, many QSA’s tell their customer that this secondary password must also be encrypted.  However because that encryption must be reversed, doing so requires a tertiary password and that must also be stored somewhere.

As should be clear by now, there are no number of iterations that eliminate the need for a plaintext password somewhere in the file system on the outbound side of the authentication request.  However, many assessmors arbitrarily force customers to make one or more iterations or to pass this requirement up to their software vendors.  This always results in a password in the clear somewhere and trivial reversal of the original, but so long as the original is not in plaintext, the assessment is satisfied because “the standard says to do it that way.”

As an alternative, some users and vendors opt for obfuscation of the password by running it through an encryption process using a key compiled into the application.  This meets the letter of the standard but is trivially reversed.  Others derive a key at runtime, but again this is trivially reversed.  If you know how the key is derived and have access to the runtime environment of the server, you can decrypt the password.  Some customers encrypt the filesystem on which the password file exists.  This is great if someone steals the disk but the standard seeks to address a completely different threat – that of data exfiltration from a live system.

Subjecting passwords to multiple layers of reversible encryption where the ultimate password is stored in the clear on the file system increases complexity and cost and provides negligible additional protection.

Furthermore, after having obfuscated the passwords, users frequently believe them to be secure and fail to protect them properly in the filesystem or in backups. The end result in many cases is a system that is less secure than when the outbound authentication passwords were in plaintext because in that case the user was cognizant of the need to protect them in the filesystem.

My proposal is as follows:

  • Distinguish in the PCI-DSS between one-way encrypted passwords on the inbound side of the access request vs. reversibly encrypted passwords on the outbound side of the access request.
  • Incorporate the existing best practices for password storage on the inbound side of the access request.  Specifically, using salt and multiple hash iterations.
  • Perform a formal threat analysis for passwords stored on the outbound side of the authentication request and prioritize the threats identified.
  • Determine what, if any, protection over and above file system protection is effective against those threats on the outbound side of the authentication.
  • Incorporate those recommendations into the standard.

Implementation of these suggestions would significantly streamline the assessment process, improve confidence of users, and ultimately improve the level of security achieved in the field.  I call on the PCI Security Council to take this proposal under consideration for their next revision.

This entry was posted in General. Bookmark the permalink.

1 Response to It’s time for sensible password security standards in the PCI-DSS

  1. Jorge says:

    I am in the middle of a PCI certification and we were having precisely the same discussion of your point above. “Subjecting passwords to multiple layers of reversible encryption where the ultimate password is stored in the clear on the file system increases complexity and cost and provides negligible additional protection.”. We already store the outbound passwords in an encrypted filesystem and send them over SSL connections to each system. Do we still need to encrypt the passwords? What is the best practice that actually provides security and compliance with PCI?

Leave a Reply to Jorge Cancel reply