Hacker News Reader

Comment by nostromo | Hacker News Reader

"The data stolen may have included names, email addresses, telephone numbers, dates of birth and hashed passwords but may not have included unprotected passwords, payment card data or bank account information, the company said."

What's the difference between "may have" and "may not have" in this context?

It seems like they're saying anything could have been stolen.

View on HN

It's lawyer talk. They don't want to say anything definitively in case they have to walk it back.

That is an incredibly deceptive sentence. They should have listed everything under "may have", unless I'm misunderstanding because they used some convoluted English.

No, it's intentionally deceptive.

The way I read it is that the stolen data has a relatively high probability of including the first set of things, but a relatively low probability of including the second set of things. They don't want to say definitively for whatever reason.

I take it as "as far as we know, these weren't stolen, but don't sue us if we turn out to be wrong".

Possibly, although they may have phrased it that way precisely to elicit your generous interpretation. Even in the scenario that they knew unprotected passwords were just as likely to have been stolen as properly protected ones.

I don't know about that, sounds to me like they're still in the process of investigating and they don't want to use any absolutes. "We think these were stolen, but we don't think these were" is what I take from it.

Or perhaps wasn't stolen, during the year that may or may not have been 2014. Sorry, ALLEGEDLY 2014.

They seem to be trying to strike a balance between warning their users, which has to happen quickly, and knowing for sure what happened, which takes a long time to figure out.

If they are opting more toward informing users quickly, then their language can't be definitive yet.

IMO this is a good thing--much better to warn people soon, than sit on the news for another month until they've completed the forensics.

If they haven't detected any sign of intrusion on their payment servers, then it would seem those did not get hit. On the other hand, it took them until now to detect the 2014 account intrusion! So it's still possible that they will discover some problem on the payment servers as they dig deeper. Hence the use of "may not" vs. "did not."

> It seems like they're saying anything could have been stolen.

Well yes, once you know the bad guys were inside the perimeter, it's hard to rule anything out. It's possible to construct a network with internal defenses as strong as the external defenses, but most networks are not built that way. Most are still soft on the inside--get root on one server and there are pathways to others.

> may not have included unprotected passwords

Yeah, they shouldn't have unprotected passwords in any way, shape, or form. The statement makes it sound like they do store unprotected passwords, but they don't think those were stolen.

The other possibility is somehow intercepting them between SSL termination and hashing.

That's a good point. If they got ahold of Yahoo's cert key they could even grab passwords before SSL termination.

Not passively anymore: login.yahoo.com is negotiating PFS ciphersuites which the private key can't decrypt without a copy of the ephemeral ECDHE parameters.

I read it as perhaps some old dormant accounts never got migrated out of an ancient DB, and may have been picked up with the rest of the data.

Yahoo is an old company, I'm sure procedures have changed drastically over the years.

Is that good? They have poor data handling and sunsetting protocols is what you're saying.

UK law requires that personal data is not kept for longer than is necessary and is securely handled and such. So if those passwords in an "ancient DB" had personal data associated with them (real names, say) then they've been breaking the law (for a long time, is the implication).

Surely if you had passwords in old DBs then when you introduce hashing you salt and hash them and sanitise the DB and all backups ... having them still hanging around is a significant failure too. But yes, not as significant as having plaintext passwords in DBs now would be.

Interesting point on the UK laws, but I doubt PII is kept alongside login data, just referenced, and removed as needed without removing a user's login credentials.

Far from an expert, but hasn't flagging an account as needing a password change on next login been used as a way to migrate to properly encrypted passwords in the past?

Often. But you want to back it up with a blanket invalidation and password deletion after some grace period, to deal with the case where the user just never logs back in - and a password reset process outside the auth flow, to handle anyone who comes back after that.

A strategy that has worked great for me transitioning off of poorly-thought-out legacy password storage schemes is to take the "bad" hash you have for everyone and treat it exactly as you would a plaintext password - in other words, salt and properly hash it the same way the new passwords are done. Then I delete the unsafe hash and flag that account as "use the old hashing scheme on the password first before normal authentication process, then correctly re-hash and salt the password and store it normally."

"may have" = "is likely to have", "may not have" = "is not likely to have".

Similar language to athletes denying drug rumors. "I have never knowingly taken an illegal supplement, and have never been notified of having failed a drug test."

Well, "anything could have been stolen" is always true of all data stored anywhere.

Reply on news.ycombinator.com