Hash Generator

A cryptographic hash maps input of any length to a fixed-length digest. The same input always produces the same digest, and any change to the input - one bit - produces a completely different one. That is the avalanche property, and it is what makes hashes useful for detecting change.

Three properties matter. Preimage resistance means you cannot work backwards from a digest to an input. Second preimage resistance means given one input you cannot find a different input with the same digest. Collision resistance means you cannot find any two inputs that collide. When a hash is described as broken, it usually means collision resistance has fallen while preimage resistance still holds.

Hashing is not encryption and has no inverse. There is no key and no way to decrypt a digest, because the output is shorter than the input and the information is genuinely gone. When a site claims to reverse an MD5 hash, it is looking the digest up in a precomputed table of common inputs, not inverting the function.

SHA-256 is the right default for anything security-relevant. It is standardised, widely implemented, hardware-accelerated on modern CPUs, and has no known practical weaknesses. SHA-512 is often slightly faster on 64-bit hardware and gives a longer digest, which matters mainly for long-term security margins.

MD5 and SHA-1 are both broken for collision resistance, and not theoretically - practically. A chosen-prefix collision for SHA-1 was demonstrated in 2020 for roughly the cost of a modest cloud compute bill, and MD5 collisions are trivial. Neither should be used for signatures, certificates or anything where an attacker could benefit from producing two files with the same digest.

They remain acceptable for non-adversarial integrity checks - verifying a file downloaded correctly, or as a fast key in a hash table - because an accidental collision remains vanishingly unlikely. The distinction is whether anyone has an incentive to construct a collision deliberately. Many systems still publish MD5 checksums for exactly this reason, and it is defensible as long as nobody mistakes it for a security guarantee.

This is the most consequential misuse of hash functions and it is worth stating plainly. SHA-256 is designed to be fast, and that speed is exactly what makes it unsuitable for passwords. A modern GPU computes billions of SHA-256 hashes per second, so a leaked database of SHA-256 password hashes can be attacked at enormous rates. Most user passwords fall in hours.

Password hashing needs a deliberately slow, memory-hard function with a per-user salt. Argon2id is the current recommendation, with bcrypt and scrypt both still acceptable and PBKDF2 adequate where a certified primitive is required. These are tunable: you set a cost parameter so that verifying one password takes a noticeable fraction of a second, which is imperceptible to a user logging in and catastrophic for an attacker trying billions of guesses.

The salt matters independently. A unique random salt per password means identical passwords produce different hashes, which defeats rainbow tables and stops an attacker learning that two users share a password. Argon2 and bcrypt handle salting for you, which is another reason to use them rather than assembling something from a general-purpose hash.

A plain hash proves nothing about origin. Anyone can compute the digest of a message, so a digest alone does not show that the message came from someone holding a secret. If you are verifying a webhook signature or an API request, you need HMAC.

HMAC combines a hash with a secret key in a specific nested construction. Only someone with the key can produce a valid HMAC, so it authenticates as well as detects change. Stripe, GitHub and most webhook providers sign payloads with HMAC-SHA256 for this reason.

The important implementation detail is that HMAC comparison must be constant-time. A normal string comparison returns as soon as it finds a differing byte, and the timing difference leaks how many leading bytes were correct - which is enough to recover a signature byte by byte. Use your platform's `timingSafeEqual` or equivalent rather than `==`.