3

PCI-DSS states the following:

3.5 Protect any keys used to secure cardholder data against disclosure and misuse

I have a service which stores a salted bcrypt hash of the user's PAN. Assuming the bcrypt algorithm is adjusted for significant slowness, how does the 3.5 requirement apply to the salt used to calculate the hash? Do I have to protect it like a common data encryption key?

Improve this question

5 Answers 5

Reset to default
8

In my opinion, you don't. The salt cannot be used directly to get the clear PAN back, so it is not subject to requirement 3.5.

Improve this answer
3
  • 1
    +1. The salt needn't be obscured in any way. Its purpose is solely to prevent precomputation attacks (e.g. rainbow tables) from being feasible. Just don't make the salt blatantly available to anyone that wants it, and you'll be fine.
    – Polynomial
    Jul 20, 2012 at 9:11
  • Why not make the salt blatantly available to anyone that wants it? If you trust the security that protects the hashes, the salt is useless to an attacker. And if a hacker can breach security and get to the hash, he can likely get to the salts too since any legitimate mechanism to access the hash will also need to provide access to the salt.
    – Johnny
    Jan 9, 2014 at 22:29
  • Do note that the hashed value itself may well still be covered, but the salt itself gives no guidance towards the value it is used with.
    – AJ Henderson
    Jan 10, 2014 at 0:13
0

Requirement 3.5 does not apply to hashing initialization vectors.

It applies to encryption keys (such as RSA or AES keys).

Improve this answer
0
0

That's why the salt must me different for each password in the user table, to avoid pre-compilated bruteforce or rainbow attack.

But do not bother about that, just PCI DSS 3.5 does not apply to password' hash vectors.

Improve this answer
0

The requirement is to protect keys. Hashing does not use keys. In fact, hashing is not even encryption.

That is why the requirement does not apply to the salt used in your question.

Beyond semantics, there is no good reason to keep the salt confidential. It can not be used to recover the unhashed message. Knowledge of the salt does not weaken the strength of the hashing algorithm. It is a common mistake for people to believe that hash values are related to confidentiality, probably because ofthe attention they have been getting in the context of securely enabling password protection access control.

Of course, the only scenario for using hashes is to ensure information integrity.

Improve this answer
-2

If the salt is known to an attacker, the feasibility of a brute-force attack depends on the slowness factor.

A sufficiently slow hash function is in my opinion not subject to the 3.5 requirement.

But if it's sufficiently slow (this depends on whether any digits are available in clear text), it may be too slow for you as well (in satisfying your business requirements).

For instance, if you're processing transactions at a high frequency, having a slow matching function is not acceptable.

Improve this answer
2
  • 1
    The salt is there to make rainbow table attacks impossible. The salt has nothing to do with the slowness factor. You should be using a slow (bcrypt or the like) hash regardless. Slow is also relative: You are very unlikely to be processing transactions anywhere near the frequency an attacker will be trying to brute force or dictionary attack the hash.
    – Tracy Reed
    Jan 10, 2014 at 1:28
  • It's a different case with a PAN because the set of possible inputs is very limited. You have no use for a rainbow table. I agree that slow is relative, but if you know the algorithm, then you can just throw more CPU at the problem.
    – malthe
    Jan 10, 2014 at 8:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .