Hashing Guide: How Hash Functions Work and Where Security Teams Use Them

Hashing turns any input, a file, a password or an API token, into a short fixed-length fingerprint that cannot be turned back into the input. A cryptographic hash function such as SHA-256 always gives the same digest for the same input, and a completely different digest if even one bit changes. Security teams rely on that behaviour every day, for file integrity checks, digital signatures, message authentication, password storage and storing API keys safely, yet the same word covers tools with very different jobs. This guide explains what a hash is in plain terms, then gives the practitioner detail: the three security properties, the SHA-2 and SHA-3 families, why MD5 and SHA-1 are finished, HMAC, password hashing parameters and how to hash tokens at rest. For the wider set of primitives, see the Cryptography Basics Guide.

Key takeaways

• A hash is a fingerprint, not encryption. There is no key and nothing to decrypt, so a hash proves data has not changed only when the expected digest comes from somewhere the attacker cannot touch.
• Use SHA-2 or SHA-3 for general hashing. SHA-256 and SHA-384 (FIPS 180-4) and SHA3-256 (FIPS 202) are approved; MD5 is broken and NIST will retire SHA-1 by 31 December 2030.
• Add a key when you need authenticity. HMAC (FIPS 198-1) proves a message came from someone holding the shared key; a bare hash proves nothing about who produced it.
• Passwords need slow, salted hashing. Use Argon2id, scrypt, bcrypt or PBKDF2 with the OWASP parameters, a unique salt per password and the scheme and cost stored with each hash.
• Hash high-entropy tokens before you store them. API keys and tokens your service verifies can be stored as SHA-256 or HMAC digests, so a database leak does not hand out working credentials.

What it is

A hash function takes input of any length and returns output of a fixed length, called a digest or hash value. SHA-256 always returns 256 bits (64 hexadecimal characters), whether the input is one word or a 4 GB disk image. A cryptographic hash function adds security properties that make the digest safe to rely on when someone may be trying to cheat. FIPS 180-4 describes the purpose simply: digests make it possible to tell whether a message has been altered since its digest was created.

Three properties define a secure cryptographic hash:

• Preimage resistance: given a digest, it is infeasible to find any input that produces it. This is the "one-way" property.
• Second preimage resistance: given one input, it is infeasible to find a different input with the same digest. This is what stops someone swapping a signed file for a malicious one.
• Collision resistance: it is infeasible to find any two different inputs with the same digest. Because of the birthday bound, an n-bit hash gives only about n/2 bits of collision resistance.

How it works

SHA-2 functions split the input into fixed-size blocks (512 bits for SHA-256, 1024 bits for SHA-512), pad the final block with the message length, and feed each block through a compression function that mixes it into an internal state. The final state is the digest. SHA-3, standardised in FIPS 202 in August 2015, uses a different design called a sponge, built on the KECCAK permutation selected in NIST's SHA-3 competition. FIPS 202 also defines SHAKE128 and SHAKE256, extendable-output functions that produce output of any length; NIST approves only the four fixed-length SHA-3 functions as hash functions.

Strengths are from the NIST hash functions project page. SHA-256 and SHA-512 are Merkle-Damgard designs, so SHA-256(secret || message) is open to length extension; the Cryptography Basics Guide explains why that rules out home-made MACs.

Keyed hashing: HMAC

HMAC, defined in RFC 2104 and standardised as FIPS 198-1 (July 2008), computes H(K xor opad, H(K xor ipad, message)), where ipad is the byte 0x36 and opad the byte 0x5C repeated to the hash block size. Only holders of key K can produce or check the tag, so HMAC gives integrity and origin between parties who share a key. RFC 2104 recommends a key at least as long as the hash output and, if tags are truncated, keeping at least half the output and never fewer than 80 bits. Typical uses are webhook signatures, HS256 JWTs and post-hash password peppers. Verify tags with a constant-time comparison such as Python hmac.compare_digest. NIST has announced it will withdraw FIPS 198-1 and move its content to SP 800-224; the construction itself is unchanged.

Password hashing

Fast hashes are the wrong tool for passwords: a GPU can try billions of SHA-256 guesses per second against a stolen table (ATT&CK T1110.002 Password Cracking). Password hashing functions are deliberately slow and, in the case of Argon2id and scrypt, memory-hard, so each guess costs the attacker real resources. A salt is a unique random value stored beside each hash; it defeats precomputed rainbow tables and forces attackers to crack each password separately. A pepper is a secret shared across all passwords and stored outside the database, in a vault or HSM.

NIST SP 800-63B-4 section 3.1.1.2 requires a salt of at least 32 bits, recommends an approved scheme from SP 800-132, a cost factor as high as practical and a stored reference to the scheme and cost for each password, and requires any optional secret key to be stored separately from the hashes, ideally in an HSM, TEE or TPM. OWASP suggests keeping hash computation under one second and recommends the PHC string format (for example $argon2id$v=19$m=19456,t=2,p=1$...) so old and new parameters can coexist. Policy on length and composition belongs in the Password Security Guide.

Hashing API keys and tokens at rest

An API key or bearer token is a password for a machine, and a database of plaintext keys is a database of working credentials. When your service verifies a token, store only its digest: generate at least 128 bits of randomness from the OS CSPRNG, show the token to the user once, store SHA-256 (or HMAC-SHA256 with a server-side key held in a vault) plus a short non-secret prefix for lookup and display, and compare digests on each request. A slow password hash is unnecessary: a random 128-bit token cannot be guessed offline. Hashing does not help with tokens your service must present to someone else, such as the GitHub and Bitbucket tokens Docker Hub held to run builds: the Docker Hub breach exposed those for about 190,000 accounts, and the only defences are encryption with well-guarded keys, narrow scopes and fast revocation. See the API Key Management Guide and the Secrets Management Guide.

Why it matters

Hashes sit underneath most trust decisions: certificate and code signatures sign a digest, package managers pin dependencies by digest (npm integrity fields, pip --require-hashes, container image digests like sha256:...), Git identifies every object by hash, and file integrity monitoring compares digests against a baseline. A weak hash breaks all of them at once. SHAttered, announced on 23 February 2017 by CWI Amsterdam and Google, produced two different PDF files with the same SHA-1 digest using about 6,500 CPU-years and 110 GPU-years of computation. NIST's response, published in December 2022, was to retire SHA-1 from its remaining uses by 31 December 2030; cryptographic modules still using it after that date will not be permitted for federal purchase.

Choosing the right tool

• Detect deliberate tampering: SHA-256 or better, with the expected digest delivered over a separate trusted channel, ideally a signed manifest. A digest published on the same web server as the download protects nothing if that server is compromised.
• Prove origin between two parties: HMAC-SHA256 with a shared key. If third parties must verify, or you need non-repudiation, use a digital signature instead.
• Store passwords: Argon2id, or PBKDF2 where FIPS validation is mandatory.
• Store high-entropy tokens you verify: SHA-256 or HMAC-SHA256.
• Derive keys from a secret: HKDF or an SP 800-108 KDF, not a bare hash and not a password hash.

Small organisations usually get most of this right by using framework defaults (Django, ASP.NET Core Identity and Spring Security all ship adaptive password hashing) and a managed secrets store. Large organisations need an inventory, because MD5 and SHA-1 linger in legacy integrations, signing pipelines and vendor products; the Cryptographic Inventory and CBOM Guide covers how to find them.

Rolling out better hashing

1. Inventory: grep code and configuration for md5, sha1, MessageDigest.getInstance, hashlib and unsalted password columns; scan certificates and signing configurations for SHA-1.
2. Classify by purpose: label each use as integrity, signature, MAC, password or token storage, because the fix differs for each.
3. Fix password storage first: wrap legacy hashes (for example Argon2id over the existing MD5 value) so every account is protected at once, then rehash to plain Argon2id at next login.
4. Pilot: benchmark the chosen cost under peak login load in staging and watch authentication latency in one region or tenant before full rollout.
5. Hash stored tokens: for new tokens store only digests; for existing ones, hash in place in a migration and keep the plaintext column until verification succeeds.
6. Roll back safely: because the PHC string records scheme and parameters, verifiers can accept old and new formats side by side, so reverting a cost increase means changing configuration, not data.

Detection and measurement

• Percentage of password hashes on the current scheme and cost (target: above 95 percent within one password-reset cycle).
• Count of MD5 or SHA-1 uses in security functions found by code and certificate scans (target: zero for signatures and MACs).
• Percentage of stored API keys and tokens held only as digests.
• Median and 99th percentile password verification time, alerting if it exceeds one second or drops sharply (a sign the cost was lowered).
• Failed HMAC verifications on webhooks and signed requests, a signal of tampering or key mismatch.

Framework mapping

Common misconceptions

• "Hashed means encrypted." Encryption is reversible with a key; a hash is not. Passwords should be hashed, never encrypted, unless a legacy system truly needs the plaintext.
• "SHA-256 is fine for passwords." It is fast by design. An unsalted or single-iteration SHA-256 password table falls quickly to GPU cracking; use a password hashing function.
• "A hash proves who sent the file." Anyone can recompute a bare hash. Origin needs HMAC or a signature, and the expected digest must come from a trusted channel.
• "A salt must be secret." Salts are stored in the clear; their job is uniqueness. The secret value is the pepper, and it must live outside the database, rotated with a password reset plan if it leaks.
• "A hash is not a credential." Some protocols accept the hash itself: Windows NTLM authentication works with the NT hash, which is why pass-the-hash (T1550.002) works. See the Pass-the-Hash and Pass-the-Ticket Guide.
• "MD5 is still okay for integrity." Only against accidental corruption. Chosen-prefix collisions mean an attacker can prepare two files with the same MD5, so it must never protect a security decision.

Related concepts

• Digital signatures: sign a digest with a private key, giving origin and non-repudiation that HMAC cannot. See the Symmetric vs Asymmetric Encryption Guide.
• Certificates and PKI: a CA signs a hash of the certificate contents, which is why SHA-1 certificates were withdrawn. See the PKI Basics Guide.
• Encryption: confidentiality, reversible with a key. See the Encryption Guide.
• Post-quantum: Grover's algorithm roughly halves preimage strength, so SHA-256 and above remain suitable; the urgent quantum work is on signatures and key exchange. See the Post-Quantum Cryptography Migration Guide.

Practitioner checklist

• Publish an approved-hash list: SHA-256, SHA-384, SHA-512 and SHA3-256 for general use; MD5 and SHA-1 banned for security functions.
• Store every password with Argon2id (m=19 MiB, t=2, p=1 or stronger), or PBKDF2-HMAC-SHA256 at 600,000 iterations where FIPS is required.
• Use a unique random salt of at least 128 bits per password and record scheme and cost in PHC format.
• Hold any pepper or token-hashing HMAC key in a vault or HSM, never in the same database as the hashes.
• Store API keys and tokens your service verifies only as SHA-256 or HMAC-SHA256 digests, with a non-secret prefix for lookup.
• Verify MACs and token digests with constant-time comparison.
• Deliver expected digests for downloads and artefacts in signed manifests, and pin dependencies by digest.
• Scan code, certificates and signing pipelines for SHA-1 and MD5 and set a removal date well before 31 December 2030.
• Benchmark and raise password hashing cost on a schedule, rehashing on login.

Standards and references

• NIST: FIPS 180-4 Secure Hash Standard
• NIST: FIPS 202 SHA-3 Standard
• NIST: FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC)
• NIST: Hash Functions project, approved algorithms and security strengths
• NIST: NIST Retires SHA-1 Cryptographic Algorithm
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• OWASP: Password Storage Cheat Sheet
• IETF: RFC 9106 Argon2 Memory-Hard Function for Password Hashing

Related NHI Mgmt Group resources: Cryptography Basics Guide · Password Security Guide · API Key Management Guide · PKI Basics Guide · Cryptographic Key Management Guide