Frequent reauth doesn't make you more secure

Original Article ↗ Hacker News Discussion ↗

Authentication mechanics & terminology

  • Long subthread on “session cookies”: some use the browser definition (cleared on close, no expiry), others mean “cookie holding a session ID” with arbitrary lifetime. Several note this ambiguity causes confusion.
  • Discussion of access vs refresh tokens: many favor short‑lived access tokens with longer‑lived refresh tokens to enable revocation without constant user logins.
  • Debate over stateless JWT/OIDC vs server‑side session stores: JWTs avoid DB lookups but complicate revocation; others prefer fast in‑memory or Redis checks plus server‑side invalidation.

UX friction, productivity loss, and user workarounds

  • Many report being forced to reauth multiple times per day across SSO, VPN, email, dev tools, and web apps, often right before meetings or in the middle of work.
  • Examples: corporate Office 365/Teams, Google Workspace 14‑day defaults, Jira with 30‑minute timeouts, Zoom, Heroku’s 25‑hour sessions, EV charging apps that log users out and block charging.
  • People respond with insecure workarounds: passwords on post‑its or barcodes, keyboard macros, shared credentials, bypassing MFA, or abandoning apps entirely.

Security value vs security theater

  • Widespread agreement that frequent reauth and forced password rotation mostly create fatigue and worse passwords (incrementing suffixes, trivial patterns) without materially improving security.
  • Frequent prompts condition users to reflexively approve MFA or enter passwords, making phishing and MFA‑fatigue attacks easier.
  • Several note availability is part of security; controls that regularly block legitimate access degrade overall security posture.

Compliance, auditors, and institutional inertia

  • Commenters blame outdated standards and auditors (PCI, NIS2, some SOC2 interpretations) for enforcing rotation and short sessions even as NIST and major vendors now advise against it.
  • Organizations often keep bad policies to satisfy checklists, insurers, or to preserve plausible deniability after breaches.

Edge cases and arguments for shorter sessions

  • Some defend shorter sessions for shared or public computers, BYOD with family members nearby, and limiting the window for stolen session tokens.
  • Others counter that screen‑locking and proper device practices are more appropriate than punishing all users with global short timeouts.

Alternatives and better patterns

  • Proposed approaches: central SSO with long but revocable sessions; short‑lived access tokens plus revocable refresh tokens; risk‑based or contextual MFA; passkeys; device‑level biometrics; and OS‑level screen‑lock policies.
  • Some warn against over‑trusting device biometrics and platform ecosystems, citing hardware flaws and lock‑in.

Vendor and product complaints (and irony)

  • Heavy criticism of Apple, Google, Microsoft, Okta, and others for inconsistent, intrusive reauth flows (App Store, iCloud, Google Docs, MS Auth dialogs, etc.).
  • Several point out Tailscale itself expires device keys and requires SSO from big IdPs, calling the blog post somewhat ironic despite agreeing with its core thesis.