What is Hashing?

What Is Hashing?

Hashing is a one-way mathematical process that converts data into a fixed-length string of characters, known as a hash value or digest. Unlike encryption, hashing is designed to be irreversible -- once data has been hashed, you cannot work backwards to recover the original information.

A good analogy is a fingerprint. Just as a fingerprint uniquely identifies a person but cannot be used to reconstruct their entire body, a hash uniquely identifies a piece of data without revealing what the data actually is. Every input produces a unique output, and even the smallest change to the input produces a completely different hash.

How Hashing Works

A hashing algorithm takes an input of any length -- a single character, a paragraph, or an entire file -- and produces a fixed-length output. For example, the widely used SHA-256 algorithm always produces a 256-bit (64-character hexadecimal) output, regardless of whether the input is one byte or one gigabyte.

Key properties of a good hashing algorithm include:

• Deterministic The same input always produces the same output
• One-way You cannot derive the original data from the hash
• Collision-resistant It is computationally infeasible to find two different inputs that produce the same hash
• Avalanche effect A tiny change in the input (even one character) produces a drastically different hash

Common Hashing Algorithms

Several hashing algorithms are in widespread use:

• SHA-256 is part of the SHA-2 family and is one of the most widely used algorithms in security applications. It is considered secure for current use
• SHA-3 is the newest member of the Secure Hash Algorithm family, offering an alternative design to SHA-2
• bcrypt is specifically designed for hashing passwords, incorporating a built-in salt and adjustable work factor to resist brute-force attacks
• MD5 and SHA-1 are older algorithms that are now considered insecure for most purposes due to known collision vulnerabilities. They should not be used for new implementations

Hashing in Payment Security

Hashing plays several important roles in payment security. PCI DSS recognises hashing as an acceptable method for rendering stored cardholder data unreadable. When a card number is hashed, the resulting value can be stored and used for purposes like matching transactions or identifying returning customers, without the original card number being recoverable from the stored data.

However, PCI DSS is specific about how hashing must be implemented to be considered secure:

• The hash must be based on strong, industry-accepted cryptography
• The entire primary account number (PAN) must be hashed, not just a portion
• The hashed value and the original PAN must not be stored together
• Hashing alone is not sufficient if an attacker could use rainbow tables (precomputed tables of hash values) to reverse the process. Salting -- adding a random value to the input before hashing -- is essential to prevent this

Why Hashing Matters for Businesses

For businesses, hashing provides a way to work with sensitive data without actually holding onto the sensitive data itself. This is particularly valuable for PCI DSS compliance because it allows organisations to perform necessary business functions -- like tracking repeat customers or reconciling transactions -- without storing card numbers in a recoverable format.

The practical benefit is reduced risk. If a hashed dataset is stolen, the attacker gains nothing useful because they cannot reverse the hashes to obtain card numbers (assuming the hashing was implemented correctly with salting). This limits the potential damage from a data breach and simplifies the compliance picture.

Hashing and Telephone Payments

In telephone payment environments, hashing can be used to create a reference token for each transaction without storing the actual card data. For example, a hashed card number might be used in a CRM system to link multiple transactions from the same customer, without the CRM ever containing the real card number.

This approach is especially useful in contact centres where agents need to identify returning callers or check payment history. The agent can see that the same card has been used before (based on the hash) without ever seeing the actual card number. Combined with DTMF suppression to keep card data out of the voice channel, hashing further reduces the amount of sensitive data in the contact centre environment.

Practical Considerations

• Always use a salt when hashing payment data. Without salting, attackers can use precomputed tables to reverse common hash values
• Use current, approved algorithms. SHA-256 or SHA-3 for general hashing, bcrypt or Argon2 for passwords
• Do not store the hash and the original data in the same system -- this defeats the purpose
• Remember that hashing is one-way. If you need to retrieve the original data later, hashing is not the right tool -- you need encryption instead
• Review your hashing implementation periodically. Algorithms that are considered secure today may be weakened by future advances in computing

Hashing Beyond Payment Data

While hashing is critical for payment security, it has many other applications that businesses encounter daily. Password storage is one of the most common -- reputable systems never store passwords in plain text but instead store hashed versions. When a user logs in, the system hashes the entered password and compares it to the stored hash. Data integrity verification uses hashing to confirm that files or messages have not been tampered with during transmission. Digital signatures rely on hashing to create a compact representation of a document that can be cryptographically signed. Understanding hashing as a general-purpose security tool helps businesses make better decisions about data protection across their entire operation, not just in the payment processing context.