The Notice That Waited

Yahoo's September 22 disclosure places those two clocks next to each other. The company says information associated with at least 500 million user accounts was stolen in late 2014. Potentially affected users are now being notified and asked to change their passwords promptly. The urgency arrives with the notice. The exposure, according to Yahoo's account, arrived much earlier.

That interval is not proof that Yahoo knowingly withheld the breach for nearly two years. The announcement describes a recent investigation; it does not establish when the company first had enough information to warn users. We should not manufacture that chronology. But neither should we confuse the moment a company announces a problem with the moment its users become able to recover from it.

This is the useful question beneath the enormous number: what power does the notice actually return to the person receiving it?

What Yahoo says was taken

In his announcement, Yahoo chief information security officer Bob Lord says the stolen account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords, and, in some cases, encrypted or unencrypted security questions and answers. Yahoo says the vast majority of the hashed passwords used bcrypt.

The qualifications matter. The company is describing categories that may have been included, not establishing that every field was taken from every affected account. Its estimate is at least 500 million accounts, not a verified count of distinct people. One person can have multiple accounts. Scale is serious enough without improving the headline by silently changing its unit.

Yahoo also says its ongoing investigation suggests the stolen information did not include unprotected passwords, payment card data or bank account information. The payment and bank information, it says, was not stored in the system found to be affected. Those are meaningful limits on the disclosed incident. They are not a declaration that all possible consequences have been ruled out.

The company believes a state-sponsored actor was responsible. That is an attribution claim by Yahoo, not an independently established conclusion in this article. As Dan Goodin notes in his September 22 Ars Technica report, Lord does not identify the country or explain the evidence behind the attribution. Yahoo says the investigation has found no evidence that the actor is currently in its network.

“No evidence” is the boundary of a finding. It should not quietly become “nothing remains to worry about.” A stolen copy of account information need not remain inside the original network to retain value.

Two clocks, one missing chronology

The announcement supplies a theft period and a disclosure date. It does not supply a complete discovery timeline.

Goodin explicitly leaves open the possibility that Yahoo learned of the mass compromise only recently. That is an important restraint. A late warning can follow late discovery, slow investigation, a delayed decision to disclose, or some combination of events. These sources do not let us select one explanation and present it as settled.

From the user's side, however, those possibilities share a practical consequence: this specific warning was not available during the intervening period. A person could have changed passwords for unrelated reasons. Yahoo itself distinguishes users who have not changed theirs since 2014. We cannot say that every affected account remained equally vulnerable throughout the interval, or that earlier notice would have prevented a particular harm.

What we can say is narrower. Information about this breach could not inform a user's choices before it reached them. Notification changes what someone can reasonably be expected to do. It does not retroactively give them the choice they lacked.

An accountable chronology would therefore separate at least three events: the intrusion, the discovery of evidence sufficient to act, and the warning delivered to affected people. Each answers a different question. When did the exposure begin? When could the institution respond? When could the user respond?

That is a standard for evaluating the response, not a finding that Yahoo has violated a particular legal deadline. The September 22 statement leaves the middle of that sequence unresolved. Calling the breach old does not resolve it. Calling the investigation recent does not resolve it either.

Credit the protection that worked

Bcrypt deserves more than a passing mention before the condemnation resumes.

Password hashing is not ordinary reversible encryption. A system stores a derived value against which it can check a submitted password. An attacker holding that value can try candidate passwords and compare the results. A password-hashing mechanism designed to make each guess expensive can materially change the attacker's workload.

Yahoo's FAQ explains that bcrypt incorporates salting and repeated computation. Goodin's report describes why this makes large-scale cracking harder, while noting that the precise burden cannot be calculated without knowing Yahoo's cost setting. It also flags the unresolved phrase “vast majority.” The announcement does not identify the protection used for all remaining passwords.

Those distinctions prevent two opposite mistakes. “Hashed” does not mean every password is immediately readable. It also does not mean no password can be guessed. Weak choices, the hashing method and its configuration matter. The fact that a protective measure cannot guarantee safety is not evidence that it did nothing.

This is where indiscriminate cynicism becomes technically useless. Engineers can make a compromise less damaging even when they cannot prevent the compromise itself. Properly protecting stored passwords is one such intervention. It deserves credit without being asked to excuse the entire incident.

But bcrypt protects the password representation. It does not turn an exposed birthday into a secret again, recall a copied telephone number or erase a security answer from someone else's possession. The breach has several kinds of information in it. A strong defense around one kind does not close the discussion about the rest.

Recovery has more than one door

Yahoo says it has invalidated unencrypted security questions and answers so they cannot be used to access an account. It is asking potentially affected users to change passwords and adopt alternative verification methods. It also recommends password changes for all users who have not changed theirs since 2014.

That is not merely public-relations wallpaper. Invalidating an exposed recovery method changes what the system will accept. It addresses a route into an account rather than simply asking its owner to feel reassured.

The limits are just as concrete. Rejecting an answer at Yahoo cannot make another service reject the same answer. Yahoo therefore also advises users to change passwords and security questions and answers on other accounts where they used the same or similar information. The instruction acknowledges that the consequences need not stop at the company's boundary.

This is a peculiar feature of account security: the ordinary person is expected to remember relationships among systems that those systems do not collectively manage for them. Where else did I use that password? Which recovery questions did I answer the same way? Which old account still matters? The institution can issue one notice. The recipient may have to turn it into several separate repairs.

That observation is not a claim that every affected Yahoo user reused credentials. Nor does it show that another account was compromised. It explains why Yahoo's own advice extends beyond Yahoo, and why reporting a completed password change would be an incomplete measure of recovery.

A usable response should distinguish actions already taken by the provider, actions the user can still take, and exposures neither party can undo. Those categories are more helpful than treating “secure your account” as a single button with a reassuring finish state.

The warning has to survive the inbox

The archived September 22 FAQ contains an unusually practical detail: Yahoo says its notification email does not ask recipients to click links, contains no attachments, and does not request personal information. It warns that messages doing those things may be attempts to steal information rather than genuine notices.

This is good design at precisely the point where the recipient is under pressure. A security warning creates urgency. An instruction that makes the genuine warning distinguishable from a fraudulent one gives that urgency a safer route.

The same FAQ warns against fraudulent fee-based services pretending to offer Yahoo support and directs people to its help site. The company is not only describing a compromised database. It is acknowledging that someone seeking repair can be targeted again while looking for help.

That should shape how we judge the whole response. Publishing accurate instructions is necessary; their existence alone does not establish that every affected person received, understood or successfully used them. The available materials do not provide that outcome evidence. We should neither declare the recovery successful because a FAQ exists nor declare it useless because the breach is enormous.

The relevant test is practical. Can the person recognize the notice, reach the legitimate account controls, understand which action matters, and get assistance if the normal route fails? The hardest case is not the technically confident reader who already keeps distinct passwords. It is the person for whom the warning is the beginning of the explanation.

A security system that works only for people who already know its failure modes has outsourced too much of its safety.

Disclosure is the start of a relationship

There is a legitimate reason for Yahoo to qualify its account. The investigation is ongoing. Lord's statement explicitly says final conclusions may differ as new information emerges. Publishing uncertainty honestly is better than offering a clean story that the evidence cannot yet support.

But uncertainty has to be usable, too. Users need to know which instructions hold now, which findings remain provisional, and where an update will appear. “We are investigating” describes activity inside the institution. It does not, by itself, give anyone outside it a decision they can make.

The deeper failure to guard against is a neat internal process that mistakes its own completion for the restoration of somebody else's agency. Announcement sent. Advice posted. Questions invalidated. Those actions matter. None individually proves that the affected person can now understand and manage the remaining risk.

An accountable response would keep the burden of explanation with the institution that held the information. It would explain the chronology as it becomes known, distinguish protected data from exposed data, make recovery reachable, and leave room for users whose experience does not fit the expected workflow. That is not a promise of perfect security. It is a way to stop making the least-informed participant carry the most ambiguous part of the repair.

Yahoo's September 22 notice returns some useful choices to users. It does not return the elapsed time, settle the discovery timeline or establish every consequence of the stolen data. Holding those facts together is more demanding than either trusting the reassurance or treating every qualification as a confession.

The company can timestamp a disclosure. The person receiving it still has to work out what the timestamp leaves them able to do.