Hashing: One-Way Fingerprints for Data and Passwords

Sometimes a system needs to check whether data matches without reversing a transformation to recover the original.

A cryptographic hash provides a compact fingerprint.

A cryptographic hash function maps input of any length to a fixed-size output designed to be one-way and highly sensitive to change.

Hashing is not encryption. There is no decryption key that restores the input.

A concrete example: verifying a download

A software publisher lists the SHA-256 hash of an installation file:

8f2a...d91c

After downloading, a user computes the file's hash.

If the values match, the bytes likely match the publisher's intended file. A one-bit change produces a very different hash.

This verifies integrity only if the expected hash came from a trustworthy source. An attacker who replaces both the file and the published hash can fool the comparison.

Fixed-size output

A hash function accepts:

• An empty value
• A short password
• A book
• A multi-gigabyte disk image

and produces an output of fixed length.

SHA-256 produces 256 bits, often displayed as 64 hexadecimal characters.

Because infinitely many possible inputs map into a finite output space, collisions must exist mathematically. Security depends on making useful collisions computationally infeasible to find.

Deterministic and sensitive to change

Hash functions are deterministic: the same input produces the same output.

A tiny input change should produce an unpredictable, substantially different output, an effect called the avalanche effect.

This lets hashes detect accidental corruption and malicious modification.

Determinism also means identical unsalted passwords produce identical hashes, which is why password storage requires salts and specialized algorithms.

Preimage resistance

Given a hash output, preimage resistance means it should be infeasible to find an input that produces that hash.

This does not make weak inputs safe.

If an attacker suspects the input is one of one million common passwords, they can hash each candidate and compare. They do not need to mathematically reverse the function.

One-way design prevents direct inversion; it does not prevent guessing a small, predictable input space.

Collision resistance

A collision occurs when two different inputs produce the same hash.

Collision resistance means finding any such pair should be infeasible.

Older hash functions such as MD5 and SHA-1 have practical collision weaknesses and should not be used for security-sensitive collision resistance.

Some nonsecurity systems still use fast legacy checksums for accidental errors, but the selected function must match the adversarial threat.

Hashes and checksums

A checksum detects accidental changes caused by transmission or storage errors.

A cryptographic hash is designed to resist intentional manipulation as well.

Not every fast hash used in programming is cryptographic. Hash tables use functions optimized for distribution and speed, not necessarily preimage or collision resistance against an attacker.

Terms overlap in casual use, so ask what security property is required.

Passwords should not be stored with a fast hash

A fast hash is useful for files but dangerous for passwords because attackers can test billions of guesses.

Password storage should use a purpose-built password hashing or key-derivation function such as:

• Argon2id
• scrypt
• bcrypt
• PBKDF2 in suitable contexts

These functions are deliberately expensive and configurable. Memory-hard designs also increase the hardware cost of large-scale guessing.

The goal is to make each guess costly while keeping legitimate login practical.

Salts make each password instance unique

A salt is a random value generated separately for each password.

The system stores:

• Salt
• Password-hash output
• Algorithm and cost parameters

On login, it uses the stored salt to calculate a hash for the submitted password and compares safely.

Salts do not need to be secret. They prevent:

• Identical passwords from having identical stored outputs
• Efficient reuse of precomputed lookup tables
• One guess from being checked against every account at once

They do not make weak passwords strong, so uniqueness, length, MFA, and rate limits still matter.

Pepper is an additional secret

Some designs add a server-controlled secret called a pepper.

Unlike a salt, the pepper is not stored with each password record. It may live in a secret manager or hardware security system.

If only the password database is stolen, the attacker also needs the pepper.

Pepper rotation and availability complicate operation. It is an extra defense, not a replacement for salts and a proper password-hashing function.

Comparing hashes safely

Naive comparison may stop at the first different byte, causing tiny timing differences that leak how much matched.

Security libraries provide constant-time comparison functions for secret authentication values.

Application code should also:

• Use the stored algorithm parameters.
• Support gradual upgrades after successful login.
• Rate-limit attempts.
• Avoid revealing whether the username or password was wrong.

Password verification is a complete workflow, not one hash call.

HMAC authenticates with a shared secret

A plain hash can detect change only when the expected hash is trusted.

A hash-based message authentication code, or HMAC, combines a cryptographic hash with a secret key.

The receiver can verify that:

• The message was not changed.
• It was created by someone holding the shared secret.

HMAC is used for webhook signatures, API request authentication, and token integrity.

It does not encrypt the message. Anyone who sees the message can read it unless encryption is applied separately.

Digital signatures use asymmetric keys

A digital signature signs a hash-derived representation using a private key.

Anyone with the public key can verify that:

• The signed content has not changed.
• The holder of the private key produced the signature.

This supports software-update verification and document authenticity without sharing one secret among all verifiers.

Trust still depends on obtaining the correct public key and protecting the private key.

Content-addressed storage

Some systems name objects by their hash.

If the content changes, its name changes. This enables:

• Deduplication
• Immutable artifact references
• Integrity checking
• Reproducible dependency trees

Git uses hash-based object identifiers, and container systems use content digests.

The security of the identifier depends on the chosen hash and how the surrounding system handles collisions and trust.

Hashes do not anonymize predictable data

Hashing an email address does not make it anonymous.

An attacker can hash likely email addresses and compare them, especially when the input space is predictable.

Salting complicates cross-record comparison but may also prevent the intended matching operation.

Privacy protection requires considering linkability, auxiliary data, access, purpose, and reidentification risk. Replacing names with hashes is often only pseudonymization.

Choosing and using hash functions

Use:

• A current cryptographic hash such as SHA-256 or SHA-3 for general integrity
• HMAC for keyed message authentication
• A password-specific function for passwords
• Digital signatures when public verification is needed

Do not invent a hash or truncate outputs casually.

Use maintained libraries and understand the complete verification channel, including how expected hashes or keys are obtained.

Knowledge check

1. Why must hash collisions exist mathematically?
2. Why can a one-way hash still be vulnerable when inputs are weak passwords?
3. What does a salt accomplish?
4. How does HMAC differ from a plain hash?
5. Why does hashing an email address not automatically anonymize it?

The one idea to remember

Hashing creates a fixed-size one-way fingerprint. Its safe use depends on the goal: integrity uses cryptographic hashes, shared-secret authenticity uses HMAC, and password storage requires unique salts plus deliberately expensive password-hashing functions.