owner-admin-securitylisted

# Owner-only admin access for a one-person product The context: one owner, no security team, real customer PII behind the panel, and a genuine risk that the only device with access dies. --- ## Layer 1 — the admin key - A single high-entropy `ORDER_ADMIN_KEY` (or equivalent) in the environment. Not a password the owner chose. - Never in a repo, never in client code, never in a log line. - **Rotating it invalidates every session for free** — that is the emergency lever, so make sure session validity actually derives from it (HMAC keyed by the admin key; see `zero-js-admin-panel`). **Do not roll your own crypto.** HMAC over an expiry, `sha256` both sides before `timingSafeEqual`, HttpOnly/Secure/SameSite cookie. That is the whole design. Anything more inventive is a liability. ## Layer 2 — first login promotes to a password The owner's own refinement, and it is the right shape: > *"After someone logs in the admin panel with the admin key then from then on they use the admin > password to log in to the admin panel."* So: the **key** is the bootstrap/recovery credential, the **password** is the daily credential. The key stays rare, which is what keeps it safe. It also gets accepted on first login — a detail worth keeping, because otherwise there is a chicken-and-egg on a fresh deploy. ## Layer 3 — device binding Bind an active session to a device fingerprint (a salted hash of a stable device signal + a long-lived cookie), so a leaked key alone does not silently han