What a hash is and why it matters for website security
A hash is a one-way transformation that converts data of any size into a fixed-length string of characters. In web security, hashes are used to protect sensitive data, verify integrity, and enable secure authentication without exposing raw secrets like passwords. Unlike encryption, which is designed to be reversible with a key, a cryptographic hash is intended to be irreversible: you should not be able to recover the original input from its hash. That property is at the heart of how hashes are applied across websites, from storing user credentials to checking that files were not tampered with.
How hashing works: the key properties of cryptographic hash functions
A cryptographic hash function takes an input (often called a message) and produces a deterministic output called a digest. Repeating the same input always yields the same digest, while a small change in the input produces a drastically different digest. Good cryptographic hashes have several important properties that make them useful in security:
- Deterministic: same input → same output every time.
- Fixed output length: the digest size does not grow with input size.
- Pre-image resistance: it should be computationally infeasible to find the original input given only the hash.
- Second pre-image resistance: given one input, it should be hard to find a different input with the same hash.
- Collision resistance: it should be hard to find any two different inputs that produce the same hash.
- Avalanche effect: small changes to input produce large, unpredictable changes in output.
Common hash algorithms used on the web include SHA-256 and SHA-3 for integrity checks, while specialized password-hashing algorithms like bcrypt, PBKDF2, and Argon2 are preferred for storing passwords because they introduce computational cost that slows attackers.
Practical use cases on websites
Password storage
Storing passwords in plain text is a serious security risk. Instead, websites store a salted, hashed version of a password. The process typically looks like this: when a user creates a password, the server generates a unique salt, combines it with the password, and runs the result through a slow, memory- or CPU-intensive hash function (e.g., bcrypt or Argon2). The server stores the salt and the resulting hash. When the user logs in, the server repeats the process and compares hashes. Because the function is one-way, an attacker who steals the database cannot directly read user passwords, and the salt prevents precomputed attacks like rainbow tables.
Data integrity and file verification
Hashes are used to verify that a file or message hasn’t been changed. For example, when you download software, the vendor often publishes a SHA-256 checksum. You compute the SHA-256 hash of the downloaded file and compare it to the published checksum; a mismatch indicates tampering or corruption. In web delivery, content-addressable systems use hashes of content as identifiers, which helps detect and prevent accidental or malicious changes.
Authentication tokens and signatures
Hash-based message authentication codes (HMACs) combine a hash function with a secret key to authenticate messages or cookies. HMACs protect against tampering because an attacker without the key cannot forge a valid HMAC. In addition, many digital signature schemes, tls handshakes, and JWTs rely on hashing internally to ensure data integrity and authenticate origin.
Common mistakes and how to avoid them
One frequent error is using a fast general-purpose hash like plain SHA-256 for password storage. Fast hashes are efficient for legitimate users but also for attackers performing brute-force or dictionary attacks. Use a slow, purposely computationally expensive algorithm (bcrypt, scrypt, Argon2, or PBKDF2 with a high iteration count) and apply a unique salt for every password. Another mistake is neglecting upgrades: as hardware improves, cost parameters should be raised so that password hashing remains slow for attackers but acceptable for users. Also, never roll your own cryptographic scheme; rely on well-tested libraries and follow current best practices.
Implementation patterns
Implementing hashing correctly requires attention to details beyond choosing an algorithm. For password management, generate a cryptographically secure, per-user salt and store it with the hash. Use a recommended library that handles salts, versioning, and parameter tuning. For HMACs, use a strong secret key stored securely on the server and rotate it when needed, keeping in mind how rotation affects token validation. For integrity checks, publish hashes over a secure channel (e.g., TLS) and consider signing the hash with a private key so clients can verify authenticity as well as integrity.
Which algorithms to use today
For file integrity and general hashing needs, SHA-256 (part of the SHA-2 family) is widely used and generally secure. SHA-3 provides an alternative design with different internal structure. For passwords, prefer Argon2 if available, as it offers configurable memory hardness and is designed to resist GPU/ASIC attacks. bcrypt and PBKDF2 are still acceptable in many contexts if configured with appropriate cost parameters; scrypt adds memory hardness too. Avoid SHA-1 and other deprecated algorithms for security-sensitive uses.
Example: password hashing workflow
A typical flow when a user registers: the server generates a random salt, applies a password-hashing function (e.g., Argon2) combining the password and salt, then stores the produced hash, the salt, and the algorithm parameters. On login, the server retrieves the stored salt and parameters, hashes the submitted password the same way, and compares the result in constant time to avoid timing attacks. If the comparison matches, authentication succeeds. Keeping the algorithm parameters in the stored record allows you to increase the cost later and re-hash passwords when users log in.
Best practices checklist
- Use a cryptographically secure, per-user salt for passwords.
- Choose a slow, memory-hardened password hashing algorithm (Argon2, bcrypt, scrypt, or PBKDF2 with sufficient iterations).
- Store algorithm parameters with the hash so you can upgrade later.
- Use HMAC with a secret key for authenticating messages or cookies.
- Publish integrity hashes over secure channels and sign them when authenticity matters.
- Routinely review and raise hashing costs as hardware evolves.
Summary
Hashing turns variable-size data into a fixed-length digest and provides a foundation for several website security tasks: protecting stored passwords, verifying integrity, and authenticating messages. The most important considerations are choosing the right algorithm for the job, using salts and keys where appropriate, and configuring cost parameters so hashes remain practical for users but expensive for attackers. When implemented with tested libraries and sound operational practices, hashing significantly reduces the risk posed by data breaches and tampering.
FAQs
Is hashing the same as encryption?
No. Hashing is one-way and designed to be irreversible, producing a fixed-size digest. Encryption is reversible with the correct key and is intended for confidentiality. Use encryption for data you need to recover, and hashing for verification and non-recoverable storage like passwords.
Can I use SHA-256 to store passwords?
Plain SHA-256 is not recommended for password storage because it is too fast, enabling attackers to try many guesses quickly. Use a purpose-built password hashing function (Argon2, bcrypt, scrypt, or PBKDF2 with an appropriately high iteration count) plus a unique salt for each password.
What is a salt and why is it important?
A salt is a random value added to a password before hashing. It ensures that identical passwords produce different hashes and prevents attackers from using precomputed lookup tables. Always use a unique, cryptographically secure salt per password.
How do HMACs differ from plain hashes?
HMACs combine a hash function with a secret key to provide message authentication. While a plain hash only proves integrity, an HMAC proves both integrity and authenticity because only parties with the secret key can generate a valid HMAC.
When should I re-hash or upgrade stored hashes?
Re-hash when you adopt stronger algorithms or increase cost parameters. A common pattern is to re-hash a password the next time the user logs in, applying the new algorithm or parameters and replacing the stored hash.
