Auth & Security · 01 Identity & Cryptography

Two questions, two status codes

Every protected request passes two separate checks, always in this order.

AUTHENTICATION

Who are you?

password · token · session

fails → 401 Unauthorized

→

AUTHORIZATION

What may you do?

role · ownership · permission

fails → 403 Forbidden

→

HANDLER

Do the work

200 OK

→AuthN runs first — you cannot check permissions for someone you haven't identified.

→401 means "prove who you are again". 403 means "I know who you are — still no".

→Sessions 01–04 build the first check; sessions 05–07 build the second.

Store a hash that is slow on purpose

bcrypt turns a password into a salted, deliberately expensive hash. You store only the hash.

internal/auth/password.go

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

const cost = 12 // ~270 ms on this machine

func HashPassword(pw string) (string, error) {
    h, err := bcrypt.GenerateFromPassword(
        []byte(pw), cost)
    return string(h), err
}

func CheckPassword(hash, pw string) bool {
    err := bcrypt.CompareHashAndPassword(
        []byte(hash), []byte(pw))
    return err == nil
}

$2a$12$EcX1op6oy.w0pO8mONBPr.6ZSuiU7NbxZOJ77Mqqvt/Ef5l12frhy

■ algorithm■ cost■ random salt (22)■ hash (31)

go run ./demos/01

hash 1: $2a$12$EcX1op6oy.w0pO8mONBPr.6ZSuiU7NbxZOJ77Mqqvt/Ef5l12frhy
hash 2: $2a$12$q4/EfxVA3zOi64hBhpAxXeURCRWl3l3b9ZdDIQpBV01ZUv4mcOd7K
same?  false
right password: <nil>
wrong password: crypto/bcrypt: hashedPassword is not the hash of the given password
73-byte password: bcrypt: password length exceeds 72 bytes

REAL TIMINGS · one GenerateFromPassword call

cost 4

1 ms

cost 8

17 ms

cost 10

67 ms

cost 12

268 ms

cost 14

1.07 s

→Same password, different hash — the salt is random and lives inside the hash.

→+1 cost = 2× the work. Pick the cost that takes ~250 ms on your server.

→The cost is stored in the hash, so you can raise it later and re-hash on the next login.

→bcrypt accepts at most 72 bytes — cap password length in validation.

Mistake

Hashing passwords with SHA-256. It is built to be fast — a GPU tries billions per second. For passwords, slow is the feature.

Compare secrets without leaking time

A normal == stops at the first wrong byte. How long it takes tells an attacker how much they got right.

internal/auth/apikey.go

import "crypto/subtle"

func validKey(got, want string) bool {
    return subtle.ConstantTimeCompare(
        []byte(got), []byte(want)) == 1
}

go run ./demos/01b · 256-byte secret, avg of 2M runs

wrong at byte 0    naive    1ns   constant  101ns
wrong at byte 128  naive   52ns   constant  101ns
wrong at byte 255  naive   85ns   constant  101ns
# naive time grows with the correct prefix; constant never moves

→Use subtle.ConstantTimeCompare for anything secret you compare yourself: API keys, reset tokens, signatures.

✓bcrypt.CompareHashAndPassword is already constant-time.

→Same timing for unknown emails too: if the user doesn't exist, still run bcrypt against a dummy hash — otherwise ~0 ms vs ~270 ms reveals which emails are registered.

→Same message for both failures: invalid email or password.

TASK

Register & login with bcrypt

POST /register — hash with cost 12, store only the hash.
POST /login — compare; one error message for every failure.
Time a login with an unknown email and a known one — make them match.

Two questions, two status codes

Who are you?

What may you do?

Do the work

Store a hash that is slow on purpose

Compare secrets without leaking time

Register & login with bcrypt

Session 01 in four lines