CodeRigor

LESSON

Separate password-storage requirements from fast hashing

Validate two explicit bounded metadata profiles while recognizing that metadata checks are neither a KDF nor password verification.

Passwords are low-entropy human secrets, not ordinary random message keys. Fast hashing lets an attacker test guesses cheaply after a verifier database is exposed. Use a vetted adaptive salted password-hashing/KDF scheme and a tuned operational policy.

This lesson is deliberately a metadata-policy exercise. It neither implements a KDF nor verifies a password. Keeping that boundary explicit prevents a parameter checker from masquerading as an authentication system.

Metadata is one gate, not password verification
start / 3
A selected parameter policy bounds the accepted record. A vetted KDF and verifier comparison are separate operations outside this exercise.
Metadata is one gate, not password verification
A selected parameter policy bounds the accepted record. A vetted KDF and verifier comparison are separate operations outside this exercise.

The exercise selects one Argon2id profile beginning at 19 MiB, two passes and one lane, and one PBKDF2-HMAC-SHA-256 profile beginning at 600,000 iterations. OWASP’s primary guidance was checked on November 8, 2026.

The upper bounds and exact salt/digest sizes are this lab’s policy. Other vetted cost/memory tradeoffs exist. Rejecting a record here means it is outside these selected profiles, not a universal judgment about every KDF configuration.

Go
package main
import ("fmt")
func main(){
memoryMiB:=19;memoryKiB:=memoryMiB*1024;iterations:=2;fmt.Println(memoryKiB,iterations>=2)
}

A 16-byte salt can still be all zeros or reused. A 32-byte digest can still be fabricated. Metadata checks cannot prove entropy, uniqueness, correct derivation, implementation validation or regulatory compliance.

Use a suitable random source, vetted password library, versioned stored parameters and an explicit upgrade policy. Bound work factors before invoking a KDF so an attacker cannot ask a verifier to allocate arbitrary memory or run unbounded iterations.

Cost tuning belongs to the real system’s hardware, load and threat model. Measure and revisit it. The course’s HMAC record verifier is not a password store, and its random 32-byte keys should not be replaced by raw user passwords.

Four claims need different evidence
start / 3
Parameter syntax, salt quality, correct KDF derivation and operational cost require different evidence. A passing metadata check establishes only its own profile contract.
Four claims need different evidence
Parameter syntax, salt quality, correct KDF derivation and operational cost require different evidence. A passing metadata check establishes only its own profile contract.
Go
package main
import ("fmt";"crypto/rand")
func main(){
salt:=make([]byte,16);n,err:=rand.Read(salt);fmt.Println(n,len(salt),err==nil)
}

Implement the selected profiles and test weak/missing/oversized parameters, unknown algorithms and algorithm-specific fields. Explain precisely why a successful metadata check does not authenticate a user.

Next we complete the course’s actual artifact: a bounded authenticated-record signer/verifier with random application keys.

Watch & read

Free lectures, talks and readings that cover this skill from another angle. All resources →

Optional expert discussion of how Go cryptography is engineered and tested. It supports the choice of maintained libraries; the course itself supplies the introductory explanations, vectors and complete lab.