MD5, SHA-256 or bcrypt? Choosing the Right Hash for Checksums, Integrity and Passwords

A cryptographic hash is deterministic, so the same input always gives the same output. It is one way, so you cannot recover the input from the output, and a tiny change in the input changes the output completely. A good hash also resists collisions, meaning it is infeasible to find two different inputs with the same output. A hash is not encryption, because there is nothing to decrypt, and it is not a secret, because anyone can compute it.

For checking that a file arrived intact, or for cache keys and deduplication, you only need to catch random corruption. Here MD5 and CRC32 are fast and adequate, and SHA-256 is fine if you want one answer for everything. The key limitation is that none of this stops a deliberate attacker. Do not treat an MD5 match as proof that a file is authentic.

• ▸MD5 is broken for security. Collisions can be created in seconds on ordinary hardware, which has been used to forge certificates and files.
• ▸SHA-1 is also broken for collision resistance. A practical collision was shown by researchers in 2017, and major browsers and certificate authorities stopped accepting SHA-1.
• ▸SHA-256 and SHA-512, from the SHA-2 family, have no known practical attacks and are the standard choice for integrity, digital signatures and checksums that people publish for downloads.
• ▸SHA-3 is a newer, structurally different alternative, valid but rarely required.
• ▸For a message that must be authentic as well as intact, use HMAC with a secret key, not a bare hash. A plain hash can be recomputed by anyone.

This is where the wrong choice does the most damage. General hashes such as MD5, SHA-1 and SHA-256 are designed to be fast, and that is a flaw for passwords. A modern graphics card can test billions of SHA-256 guesses per second, so a leaked table of unsalted fast hashes can be cracked quickly, especially for common passwords.

• ▸Use a password hashing function designed to be slow and memory hungry: Argon2id is the current recommendation, with scrypt and bcrypt as good alternatives. PBKDF2 is acceptable where compliance requires it, with a high iteration count.
• ▸Each password needs a unique random salt, which these functions handle for you. Salts prevent the same password from producing the same hash and defeat precomputed tables.
• ▸Tune the cost so that one hash takes a noticeable fraction of a second on your servers, and raise it over time.
• ▸Never invent your own scheme, such as hashing twice or mixing in a secret by hand. Use a vetted library.
• ▸Consider a server side secret, often called a pepper, as an extra layer, stored outside the database.

• ▸A hidden trailing newline. Text typed or piped through some tools gets a newline appended, which gives a completely different hash. Compare exactly the same bytes.
• ▸A different text encoding. A string hashed as UTF-16 differs from the same string hashed as UTF-8. This tool and most web systems use UTF-8.
• ▸Line endings: a file converted between Windows and Unix line endings hashes differently.
• ▸Uppercase against lowercase hexadecimal. They are the same value written differently, so compare case insensitively.
• ▸Comparing hashes of secrets with an ordinary string comparison in code can leak timing information. Use a constant time comparison function.

• ▸Check a download for corruption: SHA-256, or MD5 if that is all that is published.
• ▸Verify a file against an attacker: SHA-256 or SHA-512 from a trusted source, ideally with a digital signature.
• ▸Cache key or deduplication: any fast hash, including MD5.
• ▸Authenticate a message: HMAC-SHA-256.
• ▸Store a password: Argon2id, scrypt or bcrypt.
• ▸Derive an encryption key from a password: Argon2id, scrypt or PBKDF2, never a plain hash.

The Hash Generator and the MD5 Generator on this site compute these digests locally in your browser, which is handy for verifying small values and for learning how a single character changes the whole output.