popertots
f9e8385d5a
- 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)
80 lines
4.2 KiB
Go
80 lines
4.2 KiB
Go
//go:build !dev && !test
|
|
|
|
package user
|
|
|
|
// Production builds (neither the `dev` nor the `test` tag) must never persist
|
|
// an unsalted digest and must never write a 2FA code in plaintext: the
|
|
// plaintext [2FA] log delivery exists ONLY in dev/test builds (twofa_dev.go)
|
|
// as a LOCAL-DEV stand-in until the email/SMS transport is wired (P6). In a
|
|
// production build there is NO delivery channel of any kind, so code issuance
|
|
// fails closed unconditionally:
|
|
//
|
|
// - a missing TWO_FACTOR_PEPPER (an unsalted digest in the 1M code space
|
|
// would be offline-brute-forceable from a log/DB leak), mirroring how
|
|
// main.go refuses to start without a strong JWT_SECRET_KEY; and
|
|
// - no delivery channel by definition — email/SMS is not wired yet (P6) and
|
|
// stdout-log delivery is a dev/test-only convenience, never a production
|
|
// channel. There is deliberately NO production opt-in to log delivery:
|
|
// writing plaintext codes to a server log anyone with backend access can
|
|
// read would defeat the account-verification 2FA gate, and issuing a code
|
|
// that can never reach the user would silently dead-end setup. Issuance is
|
|
// refused and the handlers surface errTwoFADeliveryUnavailable ("2FA
|
|
// requires an email or SMS delivery channel; contact the salon") until a
|
|
// real transport lands.
|
|
//
|
|
// The plaintext code is therefore NEVER written to the server log in a
|
|
// production build, under any configuration.
|
|
|
|
import (
|
|
"crussell/internal/twofa"
|
|
"os"
|
|
)
|
|
|
|
// init registers the production pepper reader into the shared verification
|
|
// core (crussell/internal/twofa): raw env read, no fallback — code issuance
|
|
// fails closed via twoFAEnsureIssueAllowed, so no pending code is ever
|
|
// persisted as an unsalted SHA-256 digest.
|
|
func init() {
|
|
twofa.SetPepperProvider(func() string { return os.Getenv(twoFAPepperEnv) })
|
|
}
|
|
|
|
// twoFADeliveryAvailable reports whether a 2FA code delivery channel exists in
|
|
// this build. Production: always false — email/SMS is not wired (P6) and
|
|
// stdout-log delivery is a dev/test-only local feature (twofa_dev.go), never a
|
|
// production channel. Default false: no channel, so code issuance is refused
|
|
// and setup surfaces errTwoFADeliveryUnavailable instead of a silent dead-end.
|
|
func twoFADeliveryAvailable() bool { return false }
|
|
|
|
// twoFAEnsureIssueAllowed reports whether a 2FA code may be issued in this
|
|
// deployment. Production requires TWO_FACTOR_PEPPER and, after that, a real
|
|
// delivery channel — which does not exist until email/SMS lands (P6), so
|
|
// issuance is ALWAYS refused (fail-closed): without a channel a code could
|
|
// never reach the user and would silently lock them out of the enforced
|
|
// saved-card-payments gate, and without the pepper every stored code would be
|
|
// an offline-brute-forceable unsalted digest. Delegates to the pure
|
|
// build-agnostic gate twoFAEnsureIssueAllowedStrict (twofa.go), which the
|
|
// test,dev suite also exercises directly; dev/test builds always allow
|
|
// issuance (twofa_dev.go).
|
|
//
|
|
// The pepper check is the ONLY hard gate here (plus the always-absent
|
|
// delivery channel). PEPPER-CHANGE HAZARD (Loop B finding 2): the pepper keys
|
|
// the HMAC-SHA256 of every stored pending-code hash, so CHANGING
|
|
// TWO_FACTOR_PEPPER invalidates ALL pending codes — every stored hash was
|
|
// computed with the old pepper and can never match a code minted under the
|
|
// new one. An operator who changes the pepper must re-mint every user's code
|
|
// (or have each user re-run 2FA setup), or enforced saved-card charges will
|
|
// strand customers with 400 ErrMissingOrExpired forever.
|
|
func twoFAEnsureIssueAllowed() error {
|
|
return twoFAEnsureIssueAllowedStrict()
|
|
}
|
|
|
|
// twoFADeliverCode delivers a fresh verification code to the user. Production:
|
|
// a deliberate no-op — there is no delivery channel (email/SMS unwired, P6)
|
|
// and the plaintext code is NEVER written to the server log, so this is
|
|
// unreachable (twoFAEnsureIssueAllowed already refused issuance). The
|
|
// dev/test build (twofa_dev.go) writes the [2FA] log line instead.
|
|
func twoFADeliverCode(userID, label, code string) {
|
|
// Deliberate no-op: production never logs plaintext codes, under any
|
|
// configuration. Delivery is dev/test-only until email/SMS lands (P6).
|
|
}
|