The Eye Key is shown once
HMAC + fingerprint on disk, plaintext in memory only — INV-2, and why it is non-negotiable.
The Eye Key is the developer surface of DEINO: a key that identifies and authenticates an integration, rate-limited per key. And the Eye Key plaintext is shown once, in memory, and never touches disk. That is INV-2, and it is non-negotiable.
When a developer mints an Eye Key, the plaintext appears once — on screen, in memory — and what goes to disk is the HMAC of the key and a fingerprint. The HMAC is what verifies future requests; the fingerprint is what identifies the key in logs. Neither is the key. A database compromise exposes the HMAC and the fingerprint, not the key, because the key is not there to take. The plaintext was in memory for the moment of minting and then it was gone.
HMAC on disk, plaintext in memory
The mechanism is a one-way function. The Eye Key plaintext is the input; the HMAC stored in Postgres is the output. Verification is HMAC again: a request carries the key, the server computes the HMAC, compares it to the stored one. The stored HMAC verifies the key without being the key. The fingerprint — a short, non-reversible identifier — is what the logs and the UI show, so a key can be named and revoked without its plaintext being anywhere persistent. The plaintext lives in memory for the minting and the display, and memory is where it stays.
The disk holds the verifier, not the key. A database breach exposes the HMAC and the fingerprint — the plaintext was in memory for a moment, and then it was gone.
Why this is non-negotiable
Non-negotiable means there is no feature request that relaxes it. Show me my key again is a feature request; the answer is no, mint a new one. Store the key for convenience is a feature request; the answer is no, the verifier is on disk. The reason is threat modeling: the database is the most likely thing to be exfiltrated, and a key store that the database contains is a key store a breach takes. By keeping the plaintext out of the database, the blast radius of a DB compromise is the data, not the keys. The keys are the perimeter; the data is behind it.
The fingerprint is not the key
The fingerprint is a non-reversible label — a short string that identifies a key in logs and UI without revealing it. Key abc123 made 400 requests is a log line; abc123 is the fingerprint. Revoking abc123 revokes the key. The fingerprint lets the platform talk about keys — name them, rate-limit them, revoke them — without the platform ever holding the key itself after the minting moment. The fingerprint is the name; the HMAC is the verifier; the plaintext is neither.
- HMAC on disk: the verifier, not the key. Verification computes HMAC and compares; the stored value is not reversible.
- Fingerprint on disk: a short non-reversible label for logs and UI. Name and revoke without holding the key.
- Plaintext in memory only: shown once at minting, then gone. The DB breach surface is data, not keys.
- Non-negotiable: no feature relaxes it. The answer to show me my key again is mint a new one.
The blast radius of a database compromise
A database compromise that exposes the data is a serious incident. A database compromise that exposes the data and the keys is a platform-ending incident — because the keys are how every integration authenticates, and a stolen key is a clean impersonation with no brute force. INV-2 is the invariant that keeps the keys out of the database, so the worst case is the data, not the keys. We are pre-revenue, building the POC; the invariant holds by construction, and the construction is the point — a promise to not store the key is a policy; a system that has no path to store it is a property.
A promise to not store the key is a policy someone can override. A system that has no path to store the key is a property no one has to remember. INV-2 is the second kind.
— security design note