Session Management
Implemented Controls
Server-Side Session Tokens
lib/git_gud/accounts/user_token.ex— Token schema with expiry- Tokens stored in
users_tokenstable (not client-side only) - 14-day expiry window from creation
- Token types:
:confirm,:reset_password,:update_email,:session - Reissue logic: tokens can be renewed before expiry
- Tokens stored in
Cookie Sessions
- Signed cookies with Phoenix Token
- Session data stored in signed cookies (tamper-proof)
signing_saltconfigured inendpoint.ex- 14-day remember-me persistence
- SameSite=Lax attribute on session cookies
- Secure flag set for HTTPS-only transmission
Session Lifecycle
-
renew_session/2— Session fixation prevention- Called on login to issue new session token
- Invalidates previous session token
- Prevents session fixation attacks
-
Session renewal on activity
- Tokens reissued after 7 days of inactivity
- Extends session validity without requiring re-authentication
-
disconnect_sessions/1— Cross-session invalidation- Broadcasts disconnect event to all LiveView connections for a user
- Terminates all browser tabs for invalidated tokens
- Called when tokens are revoked (e.g., password change, admin action)
Sudo Mode
- Re-authentication for sensitive operations
- Requires current password or second-factor (TOTP/WebAuthn)
- 10-minute validity window for sudo operations
- Applied to: password changes, secret access, credential management
Security Observations
Medium
Hardcoded signing salt in endpoint.ex
config/config.exs:229—live_view: [signing_salt: "FRxtZcCV"]- Salt is short (8 bytes) and appears to be a development default
- While salts don’t need to be secret, short salts reduce brute-force resistance
- Recommendation: use environment-specific salts with at least 16 bytes
- Example:
System.get_env("LIVE_VIEW_SALT", "default-change-me")
No session binding to client fingerprint
- Sessions not bound to User-Agent or IP address
- Stolen session tokens can be used from different clients
- Recommendation: add optional IP binding or User-Agent validation for high-security deployments
- Note: this conflicts with some legitimate use cases (IP rotation, proxy rotation)
Cookie signing salt not configurable
signing_saltinendpoint.exis hardcoded- If compromised, all signed cookies can be forged
- Recommendation: make salt configurable via environment variable
- Example:
config :git_gud, GitGudWeb.Endpoint, signing_salt: System.fetch_env!("PHOENIX_SIGNING_SALT")
Low
Session renewal window may be too long
- 14-day expiry with 7-day renewal may be excessive for sensitive deployments
- Recommendation: make expiry configurable via instance settings
- Consider shorter lifetimes (e.g., 24 hours) for high-security instances
No concurrent session limit
- Users can have unlimited concurrent sessions
- Recommendation: add optional concurrent session limit (e.g., 10 sessions per user)
- Include UI for managing active sessions with revocation capability