AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 56 Bitcoin

Merge branch 'refact-api-keys'

Public commit record

What the developer wrote

Authored by Nicolas Dorier

45/100 · Thin
Merge branch 'refact-api-keys'
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit refactors how BTCPay Server stores and handles API keys. Previously, the secret API key itself was used as the database primary key, meaning the full secret was stored in plaintext and appeared in URLs/revocation endpoints. Now the system creates a separate public 'key ID' (starting with 'akid_') derived from a hash of the secret, stores only a hash of the secret in the database, and uses the ID for management operations such as revocation. The change also removes the old BitPay 'Basic auth' legacy API key feature entirely. The commit is framed as a security hardening measure, but it is a large refactor rather than a single bug fix.

Recommended action

Treat this as a security-hardening change worth reviewing in production: verify the migration ran cleanly, confirm legacy BitPay API key consumers have migrated to SIN/token authentication, and ensure the 5-minute cleanup job does not break legitimate long-lived API key workflows. No immediate exploit is evident from the diff, but the scope of the refactor warrants regression testing of API key creation, authentication, and revocation.

Security signals we found

01

API key secrets no longer used as database primary key or in revocation URLs

02

Database now stores SHA256 hash of secret rather than plaintext secret for authentication lookup

03

New ephemeral Key column cleared after 5 minutes by scheduled cleanup

04

Migration deletes legacy BitPay API keys (Type=0)

05

BitPay Basic-auth API key authentication path removed entirely

06

Changelog explicitly describes this as API key hardening

Risk score

Why this scored 56/100

Our methodology →
Potential impact 18/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.