# Post-Login Visibility Is a Distinct Security Layer From Authentication Hardening ## Claim Authentication hardening — passwords, 2FA, firewalls — and post-login session visibility — active-session monitoring, login alerting, session lifecycle limits — are two separate defensive layers, and strengthening one does not compensate for neglecting the other. ## Evidence **Source**: [[3. Resources/Literature Notes/Session Hijacking, Stolen Cookies, and the Blind Spot in WordPress Security Robert Abela]] ## Scope & conditions - Holds when: a session token or cookie, once issued, functions as a standalone credential — anyone who obtains a valid session no longer needs the password or 2FA that created it, so hardening the credential-issuance step does nothing to detect or limit misuse of an already-issued session. - Breaks when: sessions are short-lived, single-use, or bound to a re-verification step for sensitive actions (step-up authentication) — at that point session lifecycle limits fold back into the authentication layer rather than remaining a distinct control. ## Links - [[3. Resources/Permanent Notes/A Hijacked Admin Session Executes Attacker Actions Under the Victim's Own Nonce]] — extends; that note documents one concrete mechanism (CSRF/nonce-riding via injected JS) by which the absence of this visibility layer is exploited - [[3. Resources/Permanent Notes/Generic Hosting Security Cannot See WordPress-Specific Attack Semantics]] — applies-in; generic infrastructure hardening (firewalls, brute-force protection) sits on the authentication side of this same split and can't see session-layer misuse either - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — applies-in; names post-login visibility as a specific, previously-undercovered gap in the hosting-security threat map <!-- atomicity: 1 idea ✓ -->