What is Hashing in Cybersecurity?

How Hashing Works

The Three Defining Properties

A cryptographic hash function has three properties that distinguish it from arbitrary data transformations. First, it is deterministic — the same input always produces the same output. Second, the output is fixed-length regardless of input size; a one-character string and a multi-gigabyte file both produce hashes of the same length (256 bits for SHA-256). Third, it is computationally one-way — given a hash output, it is computationally infeasible to derive the input that produced it.

Common Hash Algorithms

Several hash algorithms have been in widespread use over the past three decades, with very different security properties. MD5, introduced in 1992, was the dominant general-purpose hash for over a decade but is now considered cryptographically broken — practical collision attacks against MD5 have existed since the mid-2000s. SHA-1, introduced in 1995, was the federal standard for almost two decades but has been considered insecure since 2017 when Google demonstrated a practical collision. SHA-256 and SHA-512, part of the SHA-2 family, are the current industry standard for general-purpose hashing.

For password-specific hashing, purpose-built algorithms exist: bcrypt (1999, still widely used), scrypt (2009), and Argon2 (2015 password hashing competition winner). These algorithms are deliberately slow and memory-intensive to make brute-force password cracking economically impractical.

Hash Collisions

A hash collision occurs when two different inputs produce the same hash output. Because hashes are fixed-length and inputs can be any length, collisions are mathematically inevitable. The security question is whether collisions can be found in practice. For modern algorithms (SHA-256, SHA-3) finding collisions is computationally infeasible — it would require more computation than exists in the world's combined hardware. For broken algorithms (MD5, SHA-1) collisions can be found in hours on commodity hardware.

Where Hashing Appears in Security

Password Storage

The canonical security use of hashing is password storage. When a user creates a password, the application hashes it and stores the hash — not the password itself. When the user logs in, the application hashes the entered password and compares the new hash to the stored hash. If they match, the password is correct. The password itself is never stored, and even a complete database breach exposes only hashes, not credentials — assuming the hashing was done correctly.

Modern password storage layers additional protections on top of hashing: salts (random per-user values that prevent identical passwords from producing identical hashes) and key stretching (iterating the hash thousands or millions of times to slow brute-force attacks). Password hashes generated without these protections — common in legacy applications — can be cracked through rainbow table attacks that pre-compute hashes for common passwords.

File Integrity and Indicators of Compromise

File hashing produces a fingerprint that can detect unauthorized modification. File integrity monitoring tools hash critical system files and compare against baselines; any unexpected hash change indicates modification. Threat intelligence platforms distribute hashes of known malicious files as indicators of compromise; endpoint detection platforms hash files at execution and compare against IOC feeds to identify known threats.

Digital Signatures and Certificate Verification

Digital signatures combine hashing with asymmetric cryptography. The signer hashes the document, encrypts the hash with their private key, and attaches it. Verifiers hash the document themselves, decrypt the signature with the signer's public key, and compare. Matching hashes prove both authorship and that the document was not modified after signing. This pattern underlies TLS certificate validation, software code signing, and most legal-grade electronic signature systems.

Common Mistakes and Modernization

Legacy Algorithm Persistence

The most common hashing-related security issue is continued use of broken algorithms. MD5 and SHA-1 remain in production at many organizations — in legacy applications, internal certificate authorities, file integrity systems, and password storage. Each represents an ongoing risk that the hash-based control no longer provides the security it was designed to provide. The remediation work is well-understood but operationally invasive enough that many organizations defer it until forced.

Unsalted Password Hashes

Unsalted password hashes — even with strong algorithms like SHA-256 — are vulnerable to rainbow table attacks. Pre-computed hash databases for common passwords are publicly available; an attacker who obtains an unsalted hash database can identify most passwords within minutes. Modern password storage always salts before hashing, regardless of which underlying algorithm is used.

HMAC vs. Raw Hashing

For authentication of messages and API requests, raw hashing is inadequate — an attacker who can intercept the message can simply substitute a different message and recompute the hash. HMAC (Hash-based Message Authentication Code) combines a hash with a shared secret key, producing authentication that an attacker without the key cannot forge. Modern API authentication patterns use HMAC rather than raw hashing.

Modernization Roadmap

Organizations modernizing cryptographic posture typically prioritize: password storage migration (highest impact, often surfaces during incidents), TLS certificate chain audit (SHA-1 intermediates still appear), file integrity monitoring algorithm refresh, and code signing infrastructure validation. The migration work is not technically difficult but requires coordinated change management because cryptographic upgrades touch authentication and verification paths across the application stack.

Related Reading

• What is Encryption? — the related-but-distinct discipline
• What is MFA? — the authentication layer that compensates for password breaches
• File Integrity Monitoring — hashing as a defensive control
• Cyber Risk Assessment — the framework that surfaces cryptographic posture gaps

Real-World Example: The MD5 Migration Forced by a Breach

A Cloudskope engagement at a mid-market financial services firm illustrates the operational consequences of legacy algorithm persistence. The firm's customer-facing web application had been built fifteen years prior and stored user passwords using unsalted MD5 hashes — adequate by the standards of the era it was built but indefensible by current standards. The IT team had documented the technical debt; the migration had been on the roadmap for nine years; competing priorities had repeatedly displaced the work.

The forcing event was a database breach. An attacker exploited a SQL injection vulnerability in a separate application that shared the database server, exfiltrating the entire user table including the password hash column. Within 48 hours of the breach disclosure, the attacker had cracked approximately 67% of the password hashes through rainbow table lookup — the unsalted MD5 hashes were essentially equivalent to plaintext for the most common passwords.

The notification and remediation work that followed cost the firm an estimated $4.2M including credit monitoring for affected customers, forced password resets, increased customer support volume, and the migration to modern password storage that had been deferred for years. The actual technical work of migrating from unsalted MD5 to bcrypt with appropriate work factor was completed in under three weeks once the priority shifted — substantially less than the nine years of deferral, and a tiny fraction of the breach cost.

The structural lesson: cryptographic modernization is not a discretionary improvement. The cost of doing it deliberately is small; the cost of doing it after a breach is enormous and includes consequences the original deferred work would have prevented entirely.

Frequently Asked Questions

Is hashing the same as encryption?
No. Encryption is reversible — encrypted data can be decrypted back to its original form with the right key. Hashing is one-way — once data is hashed, the original cannot be recovered from the hash. They serve different security purposes: encryption protects confidentiality of data that needs to be readable later; hashing produces verifiable fingerprints of data without storing the data itself.

Can a hash be reversed?
No, not in the mathematical sense. You cannot derive the original input from a hash output. However, you can guess inputs and check whether they produce the matching hash — this is how brute-force and dictionary attacks against password hashes work. The defense is using algorithms (and salts) designed to make such guessing economically impractical.

What's the difference between MD5, SHA-1, and SHA-256?
MD5 (broken since the mid-2000s) and SHA-1 (broken since 2017) are legacy algorithms vulnerable to collision attacks. SHA-256 is the current industry standard and is not currently broken. Organizations using MD5 or SHA-1 for security-relevant purposes should migrate to SHA-256 or modern password-specific algorithms (bcrypt, Argon2) depending on the use case.

Why do password hashes need salt?
Without salt, identical passwords produce identical hashes — meaning an attacker who finds one cracked password instantly knows everyone who used the same password. Worse, attackers can pre-compute rainbow tables of hashes for common passwords and look up matches instantly. Salt — a random per-user value added before hashing — defeats both attacks by making every hash unique even for identical passwords.

How can I tell if my organization is still using weak hash algorithms?
A cryptographic posture assessment evaluates hashing usage across password storage, TLS certificate chains, file integrity monitoring, and code signing infrastructure. Common indicators include legacy applications never modernized, internal certificate authorities still issuing SHA-1 certificates, file integrity tools configured with MD5, and password storage in custom-built applications. The findings are typically straightforward to remediate but require coordinated change management.