Hashing

Applies to. Requirement 3.5.1 accepts a one-way hash based on strong cryptography, applied to the entire PAN, as one method of rendering stored PAN unreadable. 3.5.1.1 tightens this: the hash must be a keyed cryptographic hash of the whole PAN, with the key managed under Requirements 3.6 and 3.7. 3.5.1 also forbids using a hash to stand in for the removed digits of a truncated PAN, and requires extra controls where hashed and truncated versions of the same PAN both exist.

Example. A merchant wants to recognise repeat customers without storing PAN, so it stores a hash of each PAN. Under 3.5.1.1 an unkeyed hash is not enough: the merchant switches to a keyed hash, generates and stores the key in its key management system, names custodians and sets a cryptoperiod. Because the same database also holds truncated PANs for receipts, the merchant documents controls showing the two columns cannot be combined to rebuild the full number.

Limits. Hashing is one-way; there is no key that recovers the input, which distinguishes it from encryption and means a hashed PAN cannot be restored for a refund. A plain, unkeyed hash of PAN does not meet 3.5.1.1; the requirement is a keyed cryptographic hash with the key managed under 3.6 and 3.7. Hashing only part of the PAN does not meet 3.5.1, which requires the entire PAN as input. Hashing is not truncation or masking, and 3.5.1 says a hash cannot replace a truncated segment.