Deep hardening: authenticated credentials, working HTTPS, session-bound sockets, rate caps, resource bounds

[dev-luigi]

What this closes

Five structural weaknesses the security audit deferred rather than fixed. Each is a separate
commit and each was exercised against a real running server, not reasoned about.

Commit	Change
9eaa9cc	Stored BMC credentials use authenticated encryption, with an automatic backup-first conversion
8d86fef	HTTPS works with no manual certificate setup
9e0607b	A live WebSocket ends with its session; login and the auth-settings endpoints are rate-capped
e1e5b64	Parsers, caches and subprocess output are bounded; deleting a server clears its state

---

Authenticated encryption for stored credentials

The old format concealed a value but did not authenticate it, so anyone able to write to the
database could alter a stored credential undetectably. Values now use AES-256-GCM and carry a
version marker.

Existing installs convert on the first start. Nothing is re-entered. Before writing
anything the conversion copies ipmideck.db and encryption.key aside as
*.pre-authenc-<timestamp>.bak; those copies are credential-grade and the changelog says
so. Values written by older versions stay readable indefinitely — a backup archive is swapped
in before the database is opened, so an old-format value can appear on any future boot.

If nothing decrypts, the key does not belong to that data and nothing is written at all; a
single unreadable value is left alone rather than dropped; a failure logs and the boot
continues, because both formats read and losing fan control at startup would be worse.

Also: an unreadable credential no longer answers with a server error while an unreachable BMC
gets an ordinary failure — that difference distinguished the two for anyone probing.

HTTPS without manual setup

This one turned out differently than planned. HTTPS already existed — config keys, a CLI flag,
a generator, uvicorn wiring, a Settings card. What was missing:

• turning it on without a certificate fell back to plain HTTP silently
• the certificate covered only localhost, and a name mismatch is a hard browser failure with
  no click-through — unlike the unknown-issuer warning, which is expected
• no environment overrides, which is the only way a container could ever enable it
• the startup log never said which scheme was in use

A certificate is now created on demand, covers the machine's hostname and addresses, and is
marked so it can be imported into a trust store (macOS and Windows will not anchor trust on a
plain end-entity certificate). Generation failure falls back to plain HTTP with the reason
logged — being locked out of your own dashboard over a certificate problem is worse than the
cleartext you already had.

No UI was added and the setup wizard was not touched.

WebSocket lifetime and origin

The socket authorised once at the handshake and never again. Connections stay open for days,
so an expired session — or one ended by a password change — kept streaming. It is re-checked
once a minute and closed; the client sees the close code and goes to the login page instead of
retrying forever.

The handshake also accepted any Origin, which is not covered by the same-origin policy: any
page the operator visited could open a socket here carrying their cookie. The origin must now
match the Host the request was addressed to. A request with no Origin is still accepted —
command-line clients and the container health check send none.

Rate cap on credential verification

Login and the two endpoints that change authentication settings are capped at five attempts a
minute per source. The disable and reconfigure paths previously verified a password with no
counter of any kind behind them, making either an unlimited guessing oracle for anyone holding
a session.

A slot is consumed even when the password is right, or someone who already knows it would face
no limit. The rejection reuses the existing lockout wording exactly, so it cannot be told
apart from a locked account — which would itself reveal the account exists.

Password verification now also runs a throwaway comparison when the username has no row.
bcrypt is slow on purpose, so returning early made an unknown name answer in under a
millisecond against tens for a real one — a gap that reads off the wire and names the only
valid account. A rate cap lowers the sample rate; it does not remove the difference.

Resource bounds

Every parser read as many entries as handed back, and subprocess output had no byte limit —
only a wall-clock timeout, which at LAN speed is hundreds of megabytes. The sensor payload is
cached and broadcast in full, so it stayed resident and was replayed to every later client.

Caps are 4–50× the worst legitimate case and each logs when it bites, naming the limit.
That matters more than the number: a silently dropped sensor could make a fan curve's source
disappear and trip the fail-safe on a healthy machine.

Deleting a server now clears the dozen trackers keyed by its id. The cached telemetry was the
worst of it — the existing clear-cache method had never had a caller, so a deleted server kept
reappearing on the dashboard of every newly connected client.

---

Verification

Every criterion was exercised against a real uvicorn on a /tmp data directory, attacked from
outside the process with raw sockets and plain HTTP.

• Credentials: four servers written in the old format — including a multibyte password, a
  60-character one and one with a significant trailing space — converted, all four still
  decrypt to the originals, the copies hold the old format as a rollback point, and a second
  boot changes nothing.
• HTTPS: certificate created and TLS serving with zero setup; plain HTTP on that port
  refused; the certificate's names inspected; the untrusted-issuer warning verified to
  actually happen, so the documentation is proven rather than asserted; restart reuses the
  certificate; plaintext still works.
• WebSocket: three foreign-origin variants refused (including a different port on the same
  host, since cookies are shared across ports); absent Origin accepted; a held socket closed
  with code 1008 at the revalidation interval.
• Throttling: the sixth attempt refused; the message identical to the lockout message; a
  correct password throttled too; the disable endpoint capped mid-guess.
• Bounds: an 8.5 MiB / 200,000-line flood capped at 2,000 entries; 9 MiB of output capped
  at 4 MiB; a genuine 160-sensor dump untouched; the server still healthy after 300 logins
  with 1,400-character usernames.

One correction is worth mentioning, because it nearly passed. The WebSocket proof first
reported a close at 40s with code 1011 — which looks like a pass. It was uvicorn dropping
an unresponsive peer, not the revalidation: the raw client was not answering keepalive pings.
Asserting the close code rather than merely "it closed" is what caught it. Corrected, the
real behaviour is 1008 at 60s.

Gate

Check	Result
pytest	516 passed (464 on dev → +52)
ruff check .	clean
npm run test	21 passed
tsc --noEmit	clean
i18n parity	OK
SPA freshness	OK — backend/static rebuilt (frontend was touched)

Documentation impact

• README.md — the at-rest encryption bullet now says GCM and mentions the automatic
  conversion; a new Security → HTTPS section covers why the browser warns, per-platform
  import instructions (Windows/macOS/Linux/Firefox), supplying your own certificate, the
  reverse-proxy alternative, regeneration, and that server.key is credential-grade.
• CHANGELOG.md — the format change, the automatic conversion, what the .bak files are
  and that they are credential-grade, and the downgrade path.
• config.example.yaml — the https key documented, including automatic generation.
• No marketing claim is invalidated. The site says "optional HTTPS/TLS with one-click
  self-signed certificate generation" — still true, and now it also works without the click.
• Nothing needed on ipmideck/docs for this branch; the README carries the operator-facing
  detail. If you'd like the HTTPS section mirrored to en/ there, say so and I'll open the
  linked PR.

Deliberately left open

Stated here rather than left to be discovered:

1. The subprocess read is not byte-bounded. The cap applies after the read; the command
   timeout remains the bound during it. Bounding the read means replacing the pipe handling and
   rewriting six lifecycle tests whose fake process exposes no streams. The commit says so.
2. Docker cannot enable TLS yet. The container invokes uvicorn directly and never enters
   the CLI. The environment overrides here are the prerequisite; the entrypoint and its
   hardcoded http:// health check belong with the container work.
3. Behind a reverse proxy not peering over loopback, all clients share one rate bucket. The
   lever is FORWARDED_ALLOW_IPS, which uvicorn already reads — no custom header parsing was
   added, since uvicorn's is correct including CIDR.
4. A same-host process can forge X-Forwarded-For for a fresh bucket. Pre-existing uvicorn
   behaviour, but it bounds what the limiter can promise.
5. WebSocket eviction latency is up to 60s. One row read per connection per minute.
6. Sensor retention and the command log are still unbounded on disk. Real growth, but disk
   rather than memory, and capping them changes a user-visible default — their own finding.

Draft, as agreed: yours to merge, test, then main + tag.