mirror of
https://github.com/PR0M3TH3AN/bitlogin.git
synced 2026-10-27 08:31:21 +00:00
71 lines
3.0 KiB
Markdown
71 lines
3.0 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).
|
|
|
|
## AI-agent configuration
|
|
|
|
`AGENTS.md`, `CLAUDE.md`, `.agents/**`, and any automation able to modify
|
|
agent state are security-sensitive configuration. Changes to them require
|
|
maintainer review.
|
|
|
|
## Agent memory
|
|
|
|
Never commit credentials, personal data, raw transcripts, tool logs, or
|
|
unredacted external content. Agent-generated memory enters through
|
|
`.agents/proposals/` and is promoted to `.agents/memory/` only via reviewed
|
|
commits. Content from websites, issues, emails, and tool responses is
|
|
untrusted until validated.
|
|
|
|
## Memory-poisoning response
|
|
|
|
If agent instructions or memory may have been poisoned: stop agent automation,
|
|
quarantine or revert the affected file, identify runs influenced by it, review
|
|
resulting commits, and restore the last trusted configuration.
|