Hashing

Hashing converts data of any length into a fixed-length string, a process designed to be one-way: easy to compute in one direction and computationally infeasible to reverse. In payments, hashing is used to verify that data hasn't been altered, or to check a value against a stored reference, without ever needing to expose the original sensitive information itself. It's a quietly essential piece of how payment systems handle data they need to check but shouldn't need to see in the clear.

What Actually Happens When Data Gets Hashed

A hash function takes an input, a card number, a password, a file, anything at all, and produces a fixed-length output called a hash or digest. Feed the same input in again and the output is identical every time, but even a tiny change to the input produces a completely different hash, which is exactly what makes hashing useful for detecting tampering or verifying that a stored value matches what was originally submitted.

Hashing Is Not Encryption, Even Though They Get Confused

Encryption in payments is reversible by design, given the right key, because the whole point is to recover the original data later. Hashing is deliberately one-way, because the point is verification, not recovery. A blog piece comparing the two directly is worth reading for anyone who's ever mixed the two up, since choosing the wrong one for a given job can create a real security gap.

Where Hashing Shows Up In Payment Systems

Hashing is commonly used to verify that a payment message or file hasn't been altered in transit, to store values that only need to be compared rather than retrieved, and as part of the broader cryptographic toolkit that keeps sensitive systems trustworthy. It sits alongside, rather than replaces, other techniques like tokenisation, which serves a different purpose: substituting a reference value for sensitive data that still needs to be retrieved later under the right conditions.

Approved Hash Algorithms And Why That Matters

Not all hash functions are considered secure any more. NIST's own hash functions project documents which algorithms are currently approved, noting that older functions like SHA-1 have been deprecated for sensitive uses because of practical attacks discovered against them. A system still relying on an outdated hash algorithm isn't automatically broken, but it's carrying more risk than it needs to for no good reason.

Salting: The Detail That Makes Hashing Actually Secure

Hashing the same input always produces the same output, which sounds useful until you realise it means identical inputs, like two customers with the same password, produce identical hashes. Adding a unique random value, called a salt, before hashing breaks that pattern, and skipping this step is one of the more common ways an otherwise sound hashing approach ends up weaker than intended in practice.

Hashing And PCI DSS Scope

Where hashing is used on cardholder data specifically, PCI DSS sets out requirements for how that hashing needs to be implemented to actually reduce risk rather than just give the appearance of doing so. A hash implemented without proper salting or using a deprecated algorithm may not meet the standard's intent even if it technically produces a hashed value.

HSMs And Hashing: A Practical Pairing

Hashing operations that need to happen at speed and at scale, particularly ones tied to key management or authentication, are often performed inside an HSM (Hardware Security Module) rather than in general-purpose software, since the dedicated hardware is built specifically to resist tampering and side-channel attacks that could otherwise leak information about the hashing process itself.

Common Misunderstandings Worth Clearing Up

Hashing doesn't make data anonymous in a legal or regulatory sense, since a hash can often be reversed through brute-force lookup if the space of possible inputs is small enough, a card number being a good example. Treating a hashed card number as equivalent to fully removed personal data is a common and potentially costly misunderstanding that's worth correcting early rather than discovering during an audit.