How To Generate Secure Hashes
📖 Bu rehber ToolPazar ekibi tarafından hazırlanmıştır. Tüm araçlarımız ücretsiz ve reklamsızdır.
What a hash function guarantees
A cryptographic hash function takes any input and produces a fixed-length fingerprint that is (in theory) one-way: infeasible to invert, infeasible to find two inputs that collide. The “in theory” is doing a lot of work, because two of the hash functions still widely deployed — MD5 and SHA-1 — have had practical collisions published (MD5 in 2004, SHA-1 in 2017 by Google’s SHAttered attack). Using them for integrity or identity today is a known vulnerability. On top of that, hash functions are the wrong tool for passwords entirely — you want a deliberately slow password-hashing function like Argon2 or bcrypt. This guide covers which hashes are broken, which are current (SHA-256, SHA-3, BLAKE3), how collision and preimage resistance differ, the password-hashing family and why it is separate, salting and peppering, and the specific choice you should make in 2026.
MD5 — broken; do not use
Collision resistance is the hardest to maintain; it fails first when a hash weakens.
SHA-1 — broken for collisions
MD5 produces a 128-bit output. Collision attacks have been practical since 2004; in 2008 researchers forged a legitimate CA certificate using MD5 collisions. Modern GPUs can produce MD5 collisions in minutes.
SHA-2 family — current standard
Still acceptable for non-security uses: file chunking, cache-busting, non-cryptographic checksums where an attacker is not in the threat model. Never acceptable for digital signatures, certificates, integrity verification, or password hashing.
SHA-3 — different internal design
SHA-1 produces 160 bits. Theoretical attacks since 2005; Google’s SHAttered paper (2017) published a real collision, and follow-up work (Shambles, 2020) made chosen-prefix collisions practical at a cost of about $45,000 in GPU time.
BLAKE2 and BLAKE3 — fast and modern
Browsers stopped accepting SHA-1 certificates in 2017. Git still uses SHA-1 for object IDs; Linus has acknowledged the risk and the Git project is working toward SHA-256. Avoid SHA-1 for any new security-relevant use.
Passwords are different — use a KDF
SHA-3 was standardized in 2015 (FIPS 202) as a structurally different alternative to SHA-2. It uses the Keccak sponge construction where SHA-2 uses Merkle–Damgård. Output sizes are the same: SHA3-224, SHA3-256, SHA3-384, SHA3-512.
Salting
Both SHA-2 and SHA-3 are secure in 2026. Use SHA-3 if you need diversification (don’t want all your security keyed on one construction surviving), or need the variable-output SHAKE128/SHAKE256. Otherwise SHA-2 has better hardware support and is slightly faster on most CPUs.
Peppering — optional additional layer
For internal systems where you control both ends, BLAKE3 is a strong default. For interoperability with standards, pick SHA-256.
HMAC and keyed hashing
A salt is a unique random value added to the password before hashing. Defeats rainbow tables and ensures two users with the same password get different hashes.
Hash length and output representation
Minimum salt length: 16 bytes of cryptographically random data. Generate per user, store alongside the hash. Argon2, bcrypt, and scrypt store the salt embedded in their output string — you do not need to manage it separately.
Common mistakes
A pepper is a secret value, the same for every user, mixed in before hashing. Kept in application config, not in the database. If the database is stolen alone, the attacker still needs the pepper to brute-force.
Run the numbers
SHA-256 produces 32 bytes. Typical representations: