mirror of
https://github.com/PR0M3TH3AN/bitlogin.git
synced 2026-10-27 08:31:21 +00:00
thePR0M3TH3ANandClaude Sonnet 5
1dc5e6802c
Found during a real integration pass (embedding this widget in BitRoad, a separate Nostr commerce app): - Password rotation's old-locator tombstone (§18.1) is only advisory -- a relay that never processes it can keep serving the pre-rotation capsule indefinitely. loginWithPassword/changePassword previously accepted that stale capsule with only a non-blocking warning. A device that has already seen the newer generation now refuses it (RollbackDetectedError) unless the caller explicitly passes acknowledgeRollback: true for the narrower relay-lag case. The widget surfaces this as a blocking confirmation screen before claiming the signer, not a banner shown after the fact. - NIP-44 capped plaintext at 65535 bytes; added the extended-length prefix for payloads up to 2^32-1 bytes, verified byte-for-byte against the nostr-tools reference implementation (conversation keys, padding at every bucket boundary, round trips in both directions). - <bitlogin-auth> now exposes nip44Encrypt/nip44Decrypt directly on the element instance, alongside the existing getPublicKey/signEvent, so a host page can reach every capability without racing other providers for the single window.nostr slot. docs/spec.md bumped to v0.4 with the full writeup (§16.2, §29.7). 75/75 tests passing (14 new NIP-44 tests, 2 new rollback e2e tests). Co-Authored-By: Claude Sonnet 5 <[email protected]>
51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
# Security Policy
|
|
|
|
BitLogin handles private keys and password-derived secrets client-side —
|
|
security issues here can mean account takeover, not just a bug.
|
|
|
|
## Reporting a vulnerability
|
|
|
|
Please do not open a public GitHub issue for a suspected vulnerability.
|
|
|
|
Instead, use GitHub's private reporting flow: go to this repo's **Security**
|
|
tab → **Report a vulnerability**. This opens a private advisory visible only
|
|
to maintainers until a fix is ready, so details aren't public before users
|
|
can update.
|
|
|
|
Include, if you can:
|
|
- What's affected (crypto primitive, capsule format, key handling, a
|
|
specific derivation) and why it's exploitable.
|
|
- A minimal reproduction or proof of concept.
|
|
- Anything you already tried in `docs/spec.md`'s threat model that this
|
|
falls outside of.
|
|
|
|
## Scope
|
|
|
|
In scope: anything in `packages/core` (crypto, capsule construction/parsing,
|
|
Nostr relay I/O, account flows) and `packages/widget` (the crypto Web
|
|
Worker, the `window.nostr` provider, key custody boundaries between the
|
|
worker and the main thread).
|
|
|
|
Out of scope: the demo site's own UI/branding bugs that don't touch account
|
|
security — file those as normal public issues instead.
|
|
|
|
## Status
|
|
|
|
This project has not yet had an independent third-party security audit —
|
|
see the README's "What's implemented" section for the current verification
|
|
status (protocol-level test suite plus manual real-browser verification).
|
|
Treat that as part of the threat model when reporting: we'd rather hear
|
|
about a real issue than have it wait for a formal audit that hasn't happened
|
|
yet.
|
|
|
|
An external integration pass (embedding this widget in a separate Nostr
|
|
commerce app) found and fixed one real account-takeover-adjacent gap:
|
|
password rotation's old-locator tombstone (§18.1) is only advisory — a relay
|
|
that never processes it can keep serving the pre-rotation capsule
|
|
indefinitely — and the client accepted that stale capsule with only a
|
|
non-blocking warning rather than refusing it. Devices that have previously
|
|
logged in to the account (and so hold a local generation high-water mark)
|
|
now fail closed on this instead; see "Changes from v0.3" in `docs/spec.md`
|
|
and §16.2/§29.7 for the full writeup, including the residual case this does
|
|
not cover (a brand-new device with no local high-water mark).
|