Slashdot Mirror
Yahoo Insiders Believe Hackers Could Have Stolen Over 1 Billion Accounts (businessinsider.com)
An anonymous reader quotes a report from Business Insider: The actual tally of stolen user accounts from the hack Yahoo experienced could be much larger than 500 million, according to a former Yahoo executive familiar with its security practices. The former Yahoo insider says the architecture of Yahoo's back-end systems is organized in such a way that the type of breach that was reported would have exposed a much larger group of user account information. To be sure, Yahoo has said that the breach affected at least 500 million users. But the former Yahoo exec estimated the number of accounts that could have potentially been stolen could be anywhere between 1 billion and 3 billion. According to this executive, all of Yahoo's products use one main user database, or UDB, to authenticate users. So people who log into products such as Yahoo Mail, Finance, or Sports all enter their usernames and passwords, which then goes to this one central place to ensure they are legitimate, allowing them access. That database is huge, the executive said. At the time of the hack in 2014, inside were credentials for roughly 700 million to 1 billion active users accessing Yahoo products every month, along with many other inactive accounts that hadn't been deleted. In late 2013, Yahoo CEO Marissa Mayer said the company had 800 million monthly active users globally. It currently has more than 1 billion.
Just say they stole all the accounts. It's also simpler to say: "Everyone who's had a yahoo account (and still cares about it) change your passwords now."
Unbelievable!
700 million to 1 billion active users accessing Yahoo products every month
Oh and the hacking thing.
The most dangerous drug
Or perhaps Obillion, or Clitillion?
A "clitillion"? Men would never be able to figure it out.
John
I use it daily.
Ironically, I've only ever used it for their OAuth service so I could log into other smaller websites, without having to worry about their password storage security. I sure called that one well...
John
Anyone else pissed off that she can make 100's of millions of dollars just by sucking the right billionaires dick ?
I'm not so much pissed as jealous. I'm a straight guy, but I swear, find me someone who'll pay me 100's of millions of dollars for sucking a cock and you can consider it a done deal.
Just cruising through this digital world at 33 1/3 rpm...
So, here is the way to fix this sort of thing using very old, very simple, freely-available tech:
First, all passwords are hashed with salt on the client. If you want to protect a bad (brute force-able) password, you could use secret salt (i.e. a keyfile) hashing layer separately but for maximum portability known salt (like the base domain, "yahoo.com") should be used. This will protect good passwords from being brute-forced without something on the client being compromised, and offers strong protection for password reuse (regardless of whether or not reuse with different services is ill-advised, it will always happen.)
Ideally, this needs to happen via a special API call to the browser itself and not by scripting on the website. The browser is already aware of password fields (this is how it offers to remember logins for you) and thus can in principle alert you whenever an insecure passfield field (or whenever 'no legitimate password field') is present. This would prevent all but the most careless users from having a spoofed website discover their plaintext passwords. I would much prefer that the browser itself handle this hashing but even a javascript implementation of client-side hashing would be a huge improvement over the status quo, primarily because the presence of client-side hashing can be easily detected and audited whilst we have to take them at their word if they claim to be doing this all securely on the backend. (And also because a client-side hash reduces the attack surface such that a database breach or HTTPS attack alone is insufficent--with JS client-side hashing, only a successful website spoof that is undetected by the browser would reveal the plaintext password.)
Next, on the server side, the already client-hashed password is hashed a second time prior to being stored in the database. What does this accomplish? I'm glad you asked! What this means is that a simple read-only database breach does not allow an attacker to log into anyone's account. This is because if they try to use the value stored in the database (post server-hash), it will be hashed a second time prior to being compared to the value in the database, and this second hashing will result in a mismatch. Thus, a successful attack would need to either intercept the pre-server hash value in memory (a much more difficult feat, and one that will only reveal users that log in while the attack is in progress), or they need write permission to the database to overwrite the password, which should sound the alarm in two ways: one by (hopefully) causing database integrity checks to fail, and another by locking users out of their accounts.
The upside of all of this: Good passwords remain safe to reuse on other websites (so long as everyone uses these standards. Websites and apps refusing to use these standards should be aggressively warned against.) Even with bad passwords, it's much harder for attackers to gain access to accounts, and the number of accounts compromised should be reduced. And the CPU load of doing this hashing should be minimal compared with the overhead that HTTPS already imposes.
Now tell me, can anyone explain why this isn't happening yet? This sort of thing would allow us to stop insisting that the most important thing users need to do is memorize a different quality password for every single account they have (impossible for most people.) The elbow grease to do this is minimal and with enough of an outcry, we could easily shame these big name companies into adopting these standards.
(And please, for all you anonymous cowards who want to tell me that hashing with known salt values are useless... go educate yourself on the properties of cryptographically-secure hash algorithms. I don't care about pre-computed rainbow tables. This isn't about protecting weak passwords from brute force attacks. Once offline attacks become possible--which happens whenever a hashed value becomes known, provided the hashing algorithm and salt are both k