More Passwords, Please: 98 Million Leaked From 2012 Breach Of 'Russia's Yahoo' (arstechnica.com)

Sean Gallagher, writing for ArsTechnica: Another major site breach from four years ago has resurfaced. Today, LeakedSource revealed that it had received a copy of a February 2012 dump of the user database of Rambler.ru, a Russian search, news, and e-mail portal site that closely mirrors the functionality of Yahoo. The dump included usernames, passwords, and ICQ instant messaging accounts for over 98 million users. And while previous breaches uncovered by LeakedSource this year had at least some encryption of passwords, the Rambler.ru database stored user passwords in plain text -- meaning that whoever breached the database instantly had access to the e-mail accounts of all of Rambler.ru's users. The breach is the latest in a series of "mega-breaches" that LeakedSource says it is processing for release. Rambler isn't the only Russian site that has been caught storing unencrpyted passwords by hackers. In June, a hacker offered for sale the entire user database of the Russian-language social networking site VK.com (formerly VKontakte) from a breach that took place in late 2012 or early 2013; that database also included unencrypted user passwords, as ZDNet's Zach Whittaker reported.

Comments

Auth secrets should always be LOCAL

[Morgaine]

When authentication secrets are stored centrally on a website then they are always at risk, regardless of the methods used to protect them. Good sites make the stored information hard to crack, and poor sites make it easy, but they are all at risk --- from internal employee corruption if nothing else. Those secrets will leak because when stored at a single point then they are all accessible to the attacker at a single point. Mass leakage is just a matter of time.

A vastly more secure approach that has been well known for decades is based on PKI, in which the user stores their auth secret locally in a private key, one half of a {private,public} PKI key pair. The server only gets to know the user's public key, and it's pointless for an attacker to crack that because the public key is public information that can be distributed freely through keyservers. (The PGP/GnuPG keyserver network has been doing this for decades.)

When a user creates an account on some website, she provides the identifier of her chosen public key (she may have lots of them). When logging in to the account subsequently, the server looks up her public key identifier in the info held for this account, fetches her public key from the keyservers, then it sends her a random string encrypted with her public key. She decrypts it with her private key (which is only held locally by the user, nowhere else) and sends the decrypted string back. The server accepts the login if the returned string matches the random string that it picked, which is not stored anywhere and varies on every login, and it rejects the fraudulent login attempt if the match fails. All this can be completely automatic.

That's strong distributed security, and it's resistant to MITM attacks and does not store any authentication secrets on the central service so those secrets cannot leak when the service is compromised.

This kind of PKI-based approach is not rocket science. Why this old but secure scheme isn't used by websites is a big mystery. The reason isn't user inconvenience, since PKI can be packaged up to look trivial to end users if developers take the trouble. And so, websites get hacked and their users' auth secrets get revealed by the millions, surprise surprise.