Harden HTTPS agent metadata with password verifiers

[Alphasite]

What is this change about?

Harden HTTPS agent passwords against the metadata exposure reported in the discovered CVE. The agent accepts a salted HMAC-SHA256 verifier in its mbus URL and checks the original HTTP Basic Auth password with constant-time comparison. The verifier itself cannot be replayed as a password. Existing clients keep sending their original credentials.

The password must be cryptographically random. This fast verifier deliberately does not stretch weak passwords; the companion CLI warns about offline guessing. Authentication uses no concurrency limiter, wait timeout, or HTTP 503 response. Legacy plaintext authentication remains supported, and malformed verifiers prevent listener startup.

Please provide contextual information.

Companion CLI: cloudfoundry/bosh-cli#742.

Companion stemcell builder: cloudfoundry/bosh-linux-stemcell-builder#761.

The -features flag reports capabilities as JSON without starting agent services. The builder advertises http-password-hmac-sha256 from the packaged binary. This separate agent capability leaves the CPI api_version contract unchanged. Format and rollout details are in docs/http-agent-password-verifiers.md.

What tests have you run against this PR?

The earlier PBKDF2 revision passed go test -race ./mbus and go test ./app ./main ./mbus. Those results do not validate the HMAC revision. Current packages compile with go build ./mbus ./app ./main; the existing verifier fixtures and assertions have been updated but have not been rerun. The HMAC fixture was generated independently with Python's standard library.

How should this change be described in bosh-agent release notes?

Support salted HTTPS agent password verifiers to harden newly written VM metadata against reusable password exposure.

Does this PR introduce a breaking change?

Legacy authentication remains supported. The bosh-hmac-sha256$ prefix is reserved; verifier-backed passwords support 1 to 1,024 bytes. Deployments must use cryptographically random passwords.

Security scope and rollout

This is hardening, not complete remediation of historical credential exposure. Rotate exposed credentials first to invalidate historical copies. Existing VMs are not rewritten by a no-change create-env run.

Agent TLS private keys and other secrets remain in metadata. An exposed TLS private key can allow agent impersonation and compromise client passwords. Assess and rotate those credentials as appropriate; password verifiers alone do not close that exposure.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}