Using an unknown hash algorithm for passwords and be PCI-compliant?

Question

Do we need to know what hashing algorithm is employed to protect passwords at rest in regard to PCI DSS Requirement 8.2.1?

We're using a wireless access point (Yamaha WLX302) in the development branch of our payment service division.

It has a password-protected admin console where the password is hashed (or encrypted-- we can't tell) at rest. According to PCI DSS Requirement 8.2.1, we are required to verify that passwords are rendered unreadable during transmission or storage.

Our QSA insisted that we were required to identify the hash/encryption algorithm but since the manual didn't say anything about algorithm and the password hashes were completely hidden from the console^*1, we asked the vendor what algorithm was used to securely store the admin password. The vendor did not agree to disclose the algorithm in use.

So, the questions are:

1. Do we actually need to identify the hash algorithm of the passwords to be PCI-compliant?
2. Can we still be PCI-compliant without an administrative access to the password hashes?
   2.1. Since we can't see the passwords/hashes, we can't tell if they're even properly hashed^*2. Are we still covered?

---

*1: This prevents even the admin from viewing the hashed passwords so we have absolutely no idea in what format the passwords are at rest-- hence they're indeed unreadable, I think.

*2: At least we can instruct via the console command to encrypt the passwords at rest, but what if there's a security bug that all passwords are actually stored in plaintext regardless of the configuration?

Answer 1

The key phrase in 8.2.1 is 'Strong Cryptography' which is defined in the glossary as:

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). See Hashing At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.

My advice would be to copy this definition and ask the manufacturer whether the storage of passwords complies with this definition of strong cryptography or the definition of hashing (also in the glossary). If the manufacturer says yes then your QSA has to be satisfied.

If the answer is no (and if the manufacturer refuses to answer you can assume that means no) then you’re probably going to have to look at compensating controls or evidence that the password store itself is inaccessible (or regretting your purchase) or further segmentation such that a compromise of the password database would have no effect on the security of the CDE.