fix: auth/2FA security — stdout-log code delivery is dev/test-only, production fails closed until email/SMS; verification-code hashing, lockout recovery, sabredav fail-closed

- TWO_FACTOR_ALLOW_LOG_DELIVERY production opt-in REMOVED: plaintext codes are written to the stdout log ([2FA]/[VERIFY]) only in dev/test builds as a local DEV ONLY feature while email/SMS delivery (P6) is implemented. Production builds have no delivery channel and code issuance fails closed (503) under any configuration — no silent log-based code leak
- verification/2FA codes hashed at rest (HMAC-SHA256 via TWO_FACTOR_PEPPER, CHAR(64)); [VERIFY] dev log relay; per-user brute-force budget; password_reset purpose clears lockout for self-service recovery; dummy-bcrypt on login no-user path kills timing oracle
- sabredav weak-password list + entropy gate; .env.example ships fail-closed DAV_ADMIN_PASSWORD
- delete-account re-auth (current_password + fresh 2FA code when enforced)
- prod-tag suite (run-prod-tag-tests.sh) compiles and runs the production 2FA issuance gate: production ALWAYS reports no delivery channel and refuses issuance after the pepper check
- startup_checks_test SNAPSHOT_ENC_KEY values built at runtime so gitleaks sees no secret-shaped literals
- env-docs parity updated (flag removed, 38 vars)
This commit is contained in:
2026-08-22 00:34:50 +01:00
parent 1429eddd34
commit f9e8385d5a
19 changed files with 1047 additions and 472 deletions
+14 -8
View File
@@ -200,16 +200,15 @@ func initSquare() {
if enforced {
// Delivery is build-dependent (handlers/user/twofa_dev.go /
// twofa_prod.go): dev/test builds ALWAYS write the plaintext code to
// the [2FA] log line; production builds write it ONLY when the operator
// explicitly opts in with TWO_FACTOR_ALLOW_LOG_DELIVERY=true and refuse
// issuance otherwise. Warn accurately per case so the operator is never
// the local-dev [2FA] stdout log; production builds NEVER log it —
// stdout-log delivery is a dev/test-only feature, not a production
// channel. With no email/SMS transport wired yet (P6), a production
// build has NO delivery channel at all, so 2FA code issuance FAILS
// CLOSED and no user can complete 2FA setup or disable until the
// email/SMS transport lands. Warn loudly so the operator is never
// misled into thinking codes are reaching users when issuance is
// actually failing closed.
if os.Getenv("TWO_FACTOR_ALLOW_LOG_DELIVERY") == "true" {
log.Printf("WARNING: 2FA codes are delivered in PLAINTEXT via the server log ([2FA] prefix) — anyone with backend log access can defeat the account 2FA gate. Restrict log access and relay codes out-of-band; replace this loose-fake delivery with email/SMS (P6) before launch.")
} else {
log.Printf("WARNING: 2FA enforcement is ON but TWO_FACTOR_ALLOW_LOG_DELIVERY is unset: in a production build there is NO code-delivery channel (email/SMS is not wired — P6), so 2FA code issuance FAILS CLOSED and no user can complete 2FA setup or disable. Set TWO_FACTOR_ALLOW_LOG_DELIVERY=true to opt into the insecure [2FA] log-delivery channel (plaintext codes in the server log — restrict log access), or wire email/SMS (P6).")
}
log.Printf("WARNING: 2FA enforcement is ON, but this is not a dev/test build: stdout-log delivery is a LOCAL DEV ONLY feature and email/SMS is not wired yet (P6), so there is NO code-delivery channel and 2FA code issuance FAILS CLOSED — no user can complete 2FA setup or disable until email/SMS delivery is implemented. Card charges are unaffected (SCA-only). Run a dev/test build for local log-delivery testing.")
}
if !enforced && !payments.IsExplicitDevOrMockEnv() {
log.Printf("WARNING: 2FA enforcement is OFF (REQUIRE_2FA=%q) with SQUARE_ENVIRONMENT=%q (not an explicit mock/dev value). Online saved-card payments will NOT require 2FA.", os.Getenv("REQUIRE_2FA"), env)
@@ -788,6 +787,13 @@ func main() {
r.Get("/{id}/edit-request", bookings.AdminGetBookingEditRequestHandler)
r.Post("/{id}/edit-requests/{request_id}/approve", bookings.AdminApproveEditRequestHandler)
r.Post("/{id}/edit-requests/{request_id}/deny", bookings.AdminRejectEditRequestHandler)
// Admin-side loyalty redemption: the admin "Take Payment"
// PaymentModal applies the customer's pending 10% loyalty
// redemption on the booking's behalf (the customer-facing
// /bookings/{id}/apply-redemption route below stays
// RequireNonGuest). ApplyLoyaltyRedemption resolves the acting
// role from context and lets an admin redeem on any booking.
r.Post("/{id}/apply-redemption", payments.ApplyLoyaltyRedemption)
})
r.Route("/admin/users", func(r chi.Router) {