Verify Elsewhere, Store Nothing

"Firelink can let you in without ever knowing your secret. The thing that checks the PIN and the thing that grants the session are not the same thing."

One Owner for the Secret

A remote client — LAN or tailnet — can't use the loopback bypass, so it authenticates with the family PIN. But here's the ownership split: cwkPippa verifies the PIN; Firelink never stores it. Firelink forwards the entered PIN to cwkPippa's verifier, gets back a yes or no, and on 'yes' mints its own revocable, expiring session with a stable session id. The secret lives in exactly one place — one owner per fact, applied to the most sensitive fact of all. Firelink is a session-minter, not a secret-keeper.

Why Delegation Beats Duplication

The tempting shortcut is for Firelink to keep its own copy of the PIN hash 'for speed.' That copy is a second place the secret can leak, a second thing to rotate, a second thing to get subtly wrong. By delegating verification to the one component that owns the secret, Firelink shrinks its own blast radius: a full compromise of Firelink's database exposes revocable session tokens, not the family PIN. And the attempts themselves are rate-limited and audited — without ever recording the PIN, because you can't leak from a log what you never wrote to it.

Sessions Carry Their Own Careful Rules

The minted session isn't casual, either. HTTP and HTTPS listeners use distinct cookie names, and each listener accepts only its matching scheme's cookie — a cookie minted for one scheme can't be replayed on the other. Reverse-proxy and Tailscale identity headers are trusted only from explicitly configured local proxy addresses, never from every direct client (the same narrow-never-widen instinct from the loopback rule). The session is revocable and expiring, so access can be cut at any time and never lingers indefinitely. Convenience comes from the session being fast to re-establish, not from it being sloppy.

Let the component that owns a secret verify it, and let every other component delegate rather than keep a copy. A service that mints sessions off someone else's verification can be fully breached without leaking the secret it never held. Duplicate a secret 'for convenience' and you've doubled every place it can escape.

Code

Delegate verification; mint your own revocable session·python

def unlock(entered_pin, scheme, client) -> Session:
    rate_limit(client)                       # attempts throttled + audited...

    # Firelink does NOT verify or store the PIN. It asks the owner.
    ok = cwkpippa.verify_family_pin(entered_pin)   # cwkPippa holds the hash
    audit("unlock-attempt", client, ok=ok)   # ...but the PIN is NEVER recorded
    if not ok:
        raise Unauthorized()

    # On success, Firelink mints ITS OWN revocable, expiring session.
    return sessions.mint(
        id=new_session_id(),
        scheme=scheme,                       # HTTP and HTTPS get distinct cookies;
        cookie_name=cookie_for(scheme),      #   each listener accepts only its own
        expires_at=now() + TTL,              # expiring
        revocable=True,                      # cuttable at any time
    )

# Firelink's DB compromise leaks session tokens (revocable), never the PIN.
# Proxy/identity headers are trusted ONLY from configured local proxies.

Exercise

Find a system where a secret (password, API key, PIN) is checked in more than one place, or where one service keeps a copy of another's credential 'for convenience.' Map every location the secret lives. Then redesign it so one component owns and verifies the secret and the others delegate. What does a full breach of a delegating component expose now — and how much smaller is that than before?

Hint

Count the copies: each place the secret is stored or checked is a place it can leak and a place you must rotate. Delegation collapses that to one owner; everyone else holds only revocable session tokens, which you can cut without touching the underlying secret.

Verify Elsewhere, Store Nothing

One Owner for the Secret

Why Delegation Beats Duplication

Sessions Carry Their Own Careful Rules

Code

External links

Exercise

Progress

Comments 0