When is a password not a password?

I recently found myself making the statement that sometimes a password isn’t a password. Maybe it is a silly semantics argument better left to high priced lawyers, but I was feeling frustrated by a particular requirement of the Payment Card Industry (PCI) Data Security Standard (DSS). This is the standard with which some organizations that process and store credit cards must comply.

The focus of my frustration was requirement 8.4 of the PCI DSS, which says “Encrypt all passwords during transmission and storage on all system components.” I was asked whether the following scenario violated this requirement.

An application which falls under the scope of PCI required manual approval of new user account registrations. Once the account was approved the system would email the user a temporary password. The user was required to change the password upon their first login to the application. The email containing the temporary password did not include their username or even a link to the actual application.

On the surface this practice appears to violate the stated requirement. It doesn't violate the “at rest” part because the password isn't stored in cleartext on a system under your control. That leaves “transmission”, and I can’t deny that the application is transmitting a password. However, my belief is that the requirement did not apply in this situation.

Without a username, a password has little value. This is like an application transmitting the last 4 digits of a credit card number (which, incidentally, the PCI standard does allow you to store unencrypted). Using this logic, I argued that this scenario shouldn't constitute transmission of a “password” because the incomplete information rendered it unusable for authentication.

Regardless, the fact that this is only a temporary password further reduces risk. An attacker would have to read the email, determine the associated username, and find the login page all before the legitimate user first logged in. That is a pretty small window of opportunity.

If you just want to follow the letter of the requirement, send users a URL that includes a parameter containing their password. When they follow the link, prompt for their username (and preferably another piece of personal info). If the credentials match, log them into the application and prompt for a new password. Technically you didn't send them a password because it wasn't identified as such. I really don’t consider this different from a risk standpoint. Just because the PCI standard language may discourage the first approach I don't believe you can consider the second any better.

Whether you can convince the PCI council or a security examiner of this viewpoint is another matter.

Ultimately, I was rebelling against the rigidity of the PCI DSS requirement, not trying to add confusion about the term “password”. I would actually prefer that the user set up their own password during account registration, but this may not be possible given the design of this particular application. However, I was satisfied that the approach taken would reduce the risk associated with emailing a temporary password to a manageable level.