Loop B aggressive adversarial round (3 attack agents) + fix + secondary + verification:
- CRITICAL: sweep replay auto-refunds provably-created-later duplicate charges (gated on parseable CreatedAt); 22h legitimate-retry window == 22h sweep cutoff (no dead zone)
- HIGH: admin Take Payment clamps to remaining obligation (cash/giftcard/saved-card/terminal); no unintended tip from overflow; campaign credit against remaining
- HIGH: /api/services/eligible-for/{id} requires auth + owner-or-admin (DOB/age + patch-test health-data leak closed)
- HIGH: opaque refresh-token rotation (login/refresh return {token, jti, refreshToken}; refresh REQUIRES opaque token; single-use rotation; logout revokes; access token rejected at refresh)
- HIGH: saved-card charges require a REAL 2FA verification code (B6/B10) — backend gate on all 8 charge paths + shared TwoFactorCodeInput frontend component on all 7 surfaces; 2FA gate is no longer setup-flag-only
- MEDIUM: ungated CF-Connecting-IP in reserve/admin_reserve gated via exported mw.ClientIP; 2FA limiter keyed on userID alone (no header-rotation bypass); ChangePassword actually revokes JTI + refresh tokens; 2FA setup mint cooldown + persistent failed-attempt counter; campaign redemption race surfaces campaign_fully_redeemed
- Terminal saved-card VAT applied (was under-collected); age-guard reconcile failures notify; isWeakJWTSecret entropy gate; gift-card redeem per-card counter + per-user limiter; webhook signature key startup validation
- NEW internal/twofa package (single source of truth breaking the payments<->user import cycle); consolidation of duplicate 2FA hash/verify
- Frontend: refresh-token storage + rotation, TwoFactorCodeInput component, amountPaidPence in admin modal, B5/B6/B10 contract wiring; 70 frontend tests
- Tests: loop_b_fixes_test.go, internal/twofa tests, updated auth/services/profile/twofa/mw tests
All 26 backend packages pass (incl. internal/twofa); frontend 70/70 + build clean; env-docs 41/41.
62 lines
2.7 KiB
Go
62 lines
2.7 KiB
Go
//go:build dev || test
|
|
|
|
package user
|
|
|
|
// Dev/test builds (the `dev` tag, or any build with the `test` tag) keep the
|
|
// documented loose-fake 2FA delivery: the plaintext code is written to the
|
|
// server log ([2FA] prefix) as the stand-in for the not-yet-wired email/SMS
|
|
// transport (P6), and a missing TWO_FACTOR_PEPPER still falls back to the
|
|
// legacy unsalted SHA-256 digest. Production builds (!dev && !test) instead
|
|
// never log the code and fail closed without the pepper — see twofa_prod.go.
|
|
|
|
import (
|
|
"crussell/internal/twofa"
|
|
"log"
|
|
"os"
|
|
"sync"
|
|
)
|
|
|
|
// twoFAPepperWarnOnce guards the one-time warning when TWO_FACTOR_PEPPER is
|
|
// unset, so a misconfigured deployment is loudly flagged once rather than on
|
|
// every code operation. Dev/test only: production builds fail closed at
|
|
// issuance instead.
|
|
var twoFAPepperWarnOnce sync.Once
|
|
|
|
// init registers the dev/test pepper reader into the shared verification core
|
|
// (crussell/internal/twofa): the documented loose-fake fallback — the legacy
|
|
// unsalted SHA-256 digest with a one-time warning when TWO_FACTOR_PEPPER is
|
|
// unset. Production builds fail closed instead (twofa_prod.go).
|
|
func init() {
|
|
twofa.SetPepperProvider(func() string {
|
|
pepper := os.Getenv(twoFAPepperEnv)
|
|
if pepper == "" {
|
|
twoFAPepperWarnOnce.Do(func() {
|
|
log.Printf("WARNING: TWO_FACTOR_PEPPER unset — 2FA codes hashed without an HMAC pepper (falling back to unsalted SHA-256); set TWO_FACTOR_PEPPER in production so a leaked digest cannot be brute-forced offline")
|
|
})
|
|
}
|
|
return pepper
|
|
})
|
|
}
|
|
|
|
// twoFAEnsureIssueAllowed always permits code issuance in dev/test builds: the
|
|
// loose-fake delivery (the [2FA] log line) is the documented stand-in until the
|
|
// email/SMS transport is wired (P6). Production builds fail closed here — no
|
|
// TWO_FACTOR_PEPPER, no codes (see twofa_prod.go).
|
|
func twoFAEnsureIssueAllowed() error { return nil }
|
|
|
|
// twoFADeliverCode delivers a fresh verification code to the user. Dev/test:
|
|
// the [2FA] log line is the delivery channel — an operator relays the code to
|
|
// the user out-of-band until email/SMS lands. Production builds log it ONLY
|
|
// when the operator explicitly opts in via TWO_FACTOR_ALLOW_LOG_DELIVERY=true
|
|
// (see twofa_prod.go); otherwise they refuse issuance up front.
|
|
func twoFADeliverCode(userID, label, code string) {
|
|
log.Printf("[2FA] verification code for user %s (%s): %s", userID, label, code)
|
|
}
|
|
|
|
// twoFADeliveryAvailable reports whether a 2FA code delivery channel exists in
|
|
// this build. Dev/test: always true — the [2FA] log line is the delivery
|
|
// channel. Production builds only have a channel when the operator explicitly
|
|
// opted into log delivery or a real email/SMS transport is wired (P6) — see
|
|
// twofa_prod.go.
|
|
func twoFADeliveryAvailable() bool { return true }
|