Hashing & Passwords

Three operations people confuse

graph TD
H["Hashing<br/>SHA-256, bcrypt"] --> H1["one-way · no key<br/>verify by re-hashing"]
E["Encryption<br/>AES-GCM"] --> E1["two-way · needs a key<br/>recover the plaintext"]
C["Encoding<br/>base64, hex"] --> C1["reversible · no key<br/>NOT security"]

• Hashing — one-way, no key. Used for integrity (file checksums) and password storage. You can’t reverse it; you re-hash and compare.
• Encryption — two-way, with a key. Used to keep data confidential and recover it later. (symmetric encryption covers this.)
• Encoding — reversible, no key, zero security. base64/hex just re-represent bytes for transport.

Cryptographic hashes (and the broken ones)

A good hash is deterministic, fast to compute, and collision/preimage resistant. The stdlib crypto/sha256 is the workhorse for integrity:

package main

import (
"crypto/sha256"
"encoding/hex"
"fmt"
)

func main() {
data := []byte("the quick brown fox")
sum := sha256.Sum256(data)
fmt.Println("sha256:", hex.EncodeToString(sum[:]))

// Deterministic: same input -> same digest, every time.
sum2 := sha256.Sum256(data)
fmt.Println("stable:", sum == sum2)

// Avalanche: one changed byte -> a completely different digest.
other := sha256.Sum256([]byte("the quick brown fox"))
fmt.Println("differs:", sum != other)
}

MD5 and SHA-1 are broken — practical collisions exist; never use them for security. SHA-256/SHA-512 (and SHA-3, now in the stdlib) are fine for integrity and signatures. But for passwords, even SHA-256 is the wrong tool — because it’s fast.

Why passwords need a SLOW hash

A modern GPU computes billions of SHA-256 hashes per second. So a stolen database of SHA-256 passwords — even salted — falls quickly to brute force. Passwords need a hash that’s deliberately slow and memory-hard, with a tunable cost.

First, the salt: a unique random value per password so identical passwords don’t collide and rainbow tables don’t work. This runnable demo shows the problem and the fix (fixed salts here for reproducibility — real salts come from crypto/rand):

package main

import (
"crypto/sha256"
"encoding/hex"
"fmt"
)

func hashed(pw, salt string) string {
sum := sha256.Sum256([]byte(salt + pw))
return hex.EncodeToString(sum[:])[:16]
}

func main() {
// Two users, SAME password.
fmt.Println("no salt, user A:", hashed("hunter2", ""))
fmt.Println("no salt, user B:", hashed("hunter2", ""))
fmt.Println("-> identical hashes leak that the passwords match\n")

// With a unique salt each, the hashes differ.
fmt.Println("salted, user A:", hashed("hunter2", "saltA"))
fmt.Println("salted, user B:", hashed("hunter2", "saltB"))
fmt.Println("-> identical passwords now hash differently")
}

Salting fixes duplicates and rainbow tables — but it does not fix speed. For that you need a real password KDF.

The right way: argon2id or bcrypt

Use a purpose-built, slow, salted KDF. These live in golang.org/x/crypto (fenced — they run on the playground but aren’t stdlib). argon2id is the modern recommendation; bcrypt is the battle-tested classic:

import "golang.org/x/crypto/bcrypt"

// Hashing at registration. The cost (here 12) makes each hash deliberately slow.
hash, _ := bcrypt.GenerateFromPassword([]byte(password), 12)
// store `hash` — it embeds the algorithm, cost, and a random salt.

// Verifying at login — constant-time, re-derives from the embedded salt/cost.
err := bcrypt.CompareHashAndPassword(hash, []byte(attempt))
if err == nil {
	// password matches
}

import "golang.org/x/crypto/argon2"

// argon2id: memory-hard, the current best practice. Salt from crypto/rand.
key := argon2.IDKey([]byte(password), salt, 1, 64*1024, 4, 32)
// store: algorithm params + salt + key, and compare with subtle.ConstantTimeCompare

bcrypt.GenerateFromPassword generates the salt, runs the slow Blowfish-based KDF, and packs everything into one string you store. CompareHashAndPassword does verification in constant time. You tune the cost so a login takes ~100ms — trivial for one user, ruinous for an attacker guessing billions.

See also

• Symmetric encryption — the two-way counterpart, done with AEAD.
• Attacking weak crypto — cracking fast/unsalted hashes, and why slow KDFs win.
• Authentication & authorization — where password verification fits.
• Why Go for security — the crypto/subtle constant-time primitives.

Next: keeping data confidential with two-way crypto — symmetric encryption.

Related topics