Real security incidents and lessons learned

Incident 1: Equifax data breach (2017)

• Equifax knew about the vulnerability but didn't patch it for weeks.
• No authentication on critical admin endpoints.
• Insufficient monitoring: attackers accessed the system for months undetected.

1. Patch quickly: vulnerabilities in authentication/authorization code are critical.
2. Use strong authentication on all admin endpoints: not just some.
3. Monitor for unusual access patterns: failed logins, large data exports, unusual IPs.
4. Never store PII in plaintext: encrypt sensitive data at rest.

Incident 2: Facebook token leakage (2019)

• Tokens were logged on every request.
• Logs weren't encrypted or sanitized.
• No one checked what was actually in the logs.

1. Never log sensitive data: tokens, passwords, credit cards, SSNs.
2. Sanitize logs: redact tokens, replace with [REDACTED].
3. Encrypt logs at rest: assume logs can be accessed.
4. Audit log access: who can read logs and when.

Incident 3: Twitch account takeover (2020)

• Password reset didn't require the user to verify their current email first.
• Attackers could change the account email and password simultaneously.

1. Verify the account owner before password reset: send a link to the current email.
2. Don't allow changing email + password in one operation: require separate verification.
3. Use time-limited tokens for password resets: 15-30 minutes, not hours.
4. Alert users on sensitive changes: email them "your account password was reset" and a link to undo it.

Incident 4: GitHub TOTP bypass (2023)

• Recovery codes were emailed to the primary email address.
• If attackers controlled the email, they could get recovery codes.
• No rate limiting on recovery code requests.

1. Don't email recovery codes: store them securely in the app, require backup codes on setup.
2. Rate limit sensitive operations: lock the account after N failed 2FA attempts.
3. Detect account compromise: email users "someone tried to access your account" and offer to revoke sessions.
4. 2FA is not just TOTP: security keys (hardware tokens) are much stronger.

Incident 5: Cloud provider API key rotation (2021)

• Credentials were committed to version control.
• No automatic rotation (credentials lived indefinitely).
• No monitoring: the unusual instance creation wasn't detected for days.

1. Never commit credentials to version control: use environment variables or secrets managers.
2. Rotate credentials regularly: every 90 days at most.
3. Use service accounts with minimal permissions: the developer's AWS key had full access.
4. Monitor for unusual activity: alert on new instances, unusual regions, high costs.

Incident 6: Google account session fixation (2018)

• Session ID wasn't regenerated after login.
• An attacker could use a known session ID to hijack the session.

1. Always regenerate session IDs after login: don't reuse the old one.
2. Invalidate old sessions on sensitive actions: password change, email change, new device.
3. Test for session fixation: try to log in with a predetermined session ID.

Incident 7: Okta breach (2023)

• Insufficient logging and monitoring.
• No MFA on internal dashboards.
• Slow incident response.

1. Require MFA on all internal dashboards: especially for identity/auth infrastructure.
2. Log all privileged actions: view configs, change settings, export data.
3. Alert on unusual patterns: failed logins from new IPs, bulk data access.
4. Respond quickly: have an incident response plan and test it.

Common patterns from real incidents

1. Weak boundaries between privileged and unprivileged operations

• Require MFA for admin operations.
• Require re-authentication before sensitive changes.
• Log all privileged actions.

2. No detection of compromise

• Send emails on new devices / logins from unusual locations.
• Offer "View active sessions" to revoke ones the user doesn't recognize.
• Alert on unusual API usage (large data exports, bulk operations).

3. Secrets in logs/code

• Use a secrets manager (AWS Secrets Manager, HashiCorp Vault).
• Pre-commit hooks to scan for credentials.
• Rotate credentials frequently.
• Sanitize logs automatically.

4. Weak rate limiting

• Rate limit login attempts: 5 failures → 15-minute lockout.
• Rate limit password resets: 3 per day per account.
• Rate limit recovery codes: require re-authentication after 1-2 uses.

5. No monitoring

• Monitor failed logins.
• Monitor bulk exports / unusual API usage.
• Monitor new admin accounts / permission changes.
• Set up alerts and review them.

Defensive checklist

• Passwords hashed with bcrypt or Argon2 (cost ≥ 12).
• Sessions/tokens don't include sensitive data.
• Session IDs regenerated after login.
• Password resets expire after 15 minutes.
• MFA available for all accounts.
• MFA required for admin operations.
• No credentials in logs, code, or configs.
• Secrets rotated every 90 days.
• Authorization checked on every action (not just frontend).
• Tenant boundaries enforced (multi-tenant apps).
• Failed logins monitored and alerted on.
• Account changes (email, password, 2FA) emailed to user.
• Old sessions invalidated on sensitive changes.
• HTTPS only (no HTTP fallback).
• SameSite=Strict on session cookies.
• CSRF tokens on all state-changing operations.
• Rate limiting on login, password reset, API endpoints.
• Logs sanitized (no tokens, passwords, PII).
• Log access controlled and monitored.

Further reading

• Krebs on Security — Data Breaches (news site covering real breaches)
• Have I Been Pwned (check if you've been in a known breach)
• OWASP Top 10
• CWE Top 25 Most Dangerous Software Weaknesses
• Auth0 — Common Authentication Mistakes