How Attackers Steal Accounts Without Stealing Passwords
In 2022, Slack disclosed a security incident affecting a subset of users. Attackers obtained Slack session tokens — not passwords — and used them to access accounts. No password was ever compromised. The tokens alone were enough to log in as any affected user, read messages, and access workspaces.
Sessions are the mechanism that keeps you "logged in" between page loads. After you authenticate, the server issues a session token (usually a cookie) that proves your identity on subsequent requests. If an attacker gets that token, they can impersonate you — without ever knowing your password.
The session lifecycle
Understanding where sessions go wrong requires understanding the full lifecycle:
- Generation — server creates a unique, unpredictable session ID after authentication
- Storage — session data stored server-side; only the ID is given to the client
- Transmission — session ID sent as a cookie (or header) on every request
- Validation — server looks up the session ID and retrieves the stored session data
- Termination — on logout, the server-side session must be destroyed (not just the cookie)
Each step can be implemented insecurely. Real-world sessions often have multiple weaknesses at once.
Why does stealing a session token give an attacker full account access without knowing the password?