Hacker News Reader

Comment by perfectfire | Hacker News Reader

> 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.

View on HN

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."

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.

Reply on news.ycombinator.com