Eleven Days of Valid Credentials: Prioritizing a Retailer's Fixes
An online retailer with 2.4 million accounts finishes an incident review. Over eleven days, 3,100 accounts were accessed using valid credentials from 40 IP addresses - roughly 0.01% of daily logins, so no alert fired. There is no MFA. Support agents see full order history and card numbers masked to the last four digits; they work in an open-plan office and screen-share with customers, and 14% of them use shared team logins. The login endpoint returns "no account with that email" for unknown addresses and "incorrect password" for known ones. Separately, the analytics pipeline logs full request bodies - including passwords and session cookies - and has done so for 13 months. Security argues those logs are what allowed them to reconstruct the attack.
1. You have one quarter of engineering capacity. What do you fix first, and how do you justify the order?
Read the worked answer
Order by expected harm removed per unit of effort, not by severity label.
- MFA, phased by risk. The attack succeeded because a valid password was sufficient. Only a second factor changes that. Roll out to accounts with stored payment methods first, then all accounts. Everything else on this list is secondary to the fact that stolen credentials currently equal account access.
- Distinct agent identities, no shared logins. Shared credentials destroy attribution: you cannot tell who viewed what, so you cannot investigate the support-side exposure or hold anyone accountable. This is also a prerequisite for the least-privilege rework below.
- Stop logging passwords and session cookies. This is a breach amplifier: any read-only access to the analytics store becomes full credential compromise for the whole customer base. It converts a medium incident into a catastrophic one.
- Generic login errors. Cheap, quick, removes enumeration that let attackers build a target list.
- Detection. Rate limiting, breached-password checks, impossible-travel.
The justification line to use with leadership: the attacker's cheapest path was valid credentials, so the highest-leverage fix is the one that makes valid credentials insufficient. Detection, masking, and error wording reduce the attackers' convenience but do not close the path.
2. Does masking card numbers to the last four address the harm in the support tool? What does the agent's screen actually expose?
Read the worked answer
No. The masking solves a harm that is not the main one here.
The agent's screen shows order history, delivery addresses, items purchased, return reasons, gift-card activity, and possibly notes - enough to impersonate the customer in a call to another company, answer security questions, or physically locate someone. For a customer in a difficult situation, the disclosure of what they bought is the harm, not card fraud.
Two amplifiers make it worse than a normal support tool:
- Screen-sharing with "customers" means the exposure set is not the agents - it is whoever passed the identity verification on the call, plus whatever records the screen-share tool retains. A weak verification step becomes a data-disclosure channel.
- Shared team logins mean an access log records a team, not a person, so any misuse is unattributable.
The fix is not more masking. It is least privilege plus deliberate revelation: show the minimum needed for the ticket type, require a stated reason to reveal sensitive fields, log every reveal with the agent identity, and rotate or eliminate shared accounts. Masking is a display property; what you need is an access property.
3. The password logging must stop, but security depends on those logs. Resolve the conflict rather than picking a side.
Read the worked answer
Decompose "the logs" into what security actually needed and what must not exist.
Forensic reconstruction of this attack used timestamps, source IPs, user agents, paths, status codes, and account identifiers. It did not need plaintext passwords or session cookies. Those fields add zero investigative value and maximum exposure.
Resolution:
- Allowlist at the collector, not redaction downstream. A structured logger that only accepts declared fields means new fields cannot leak in by default - the failure mode that created this problem.
- Tiered retention. Metadata retained for the 13 months security wants. Full-fidelity bodies, if ever needed for a narrow debugging window, capped at hours in restricted storage with access logging and automatic purge.
- Revoke the exposure. Treat every password and session token in that pipeline as compromised: force resets for affected accounts, invalidate sessions, and check whether the analytics store was in scope for any access review.
- Prove it still works. Walk security through a tabletop replay of the actual incident using metadata only. If they can reconstruct it, the argument is settled with evidence rather than authority.
This is the standard shape of the conflict: the request is legitimate, the implementation is not, and the engineer's job is to find the version that satisfies both - not to choose which stakeholder to disappoint.