More Passwords, Please: 98 Million Leaked From 2012 Breach Of 'Russia's Yahoo' (arstechnica.com) 23
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.
Re: (Score:2)
Wanna know what is more useful than storing plaintext passwords? Storing plaintext incorrect passwords.
Re: (Score:2)
I can't understand in any way, that a site that size can be running with plain text passwords. In 2012.
Don't attribute to stupidity anything which can adequately be explained by malice.
Maybe somebody wanted your password. Lots and lots of people use the same password for everything. Maybe these sites were using people's passwords to sniff their Facebook accounts, their email, who-knows-what...?
It really is the way some CEOs think, and what they'll order their programmers to do.
Re: (Score:2)
Well if someone wants my ICQ password they're welcome to it. I don't think I've used it since 2001 and have had many passwords since.
ICQ (Score:2)
Re: (Score:2)
I don't use it anymore, but I looked it up a few months ago, and it actually seems to be a pretty good solution. It has clients for just about every device and operating system. Which seems a lot better than any of the other instant messaging systems that seem to want to limit themselves to certain devices. Services like iMessage or Snapchat come to mind. I didn't actually download and try it, so I can't speak to the quality of how well it works, but it does look like it at least tries to be supported on j
Re: (Score:1)
Re: (Score:2)
A couple people and I still do, but rarely. However, we don't use native clients. We use third parties like Trillian, Pidgin/Finch, etc. I am disappointed with Yahoo! for locking them out. :(
Auth secrets should always be LOCAL (Score:3)
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.
Re: (Score:2)
Huh?
People have been hashing passwords since the 1970's. It's a solved problem, one extra line of code and all programmers know about it.
If these sites are storing passwords in plain text it's because they WANT to store them in plain text. They're using them for something (eg. sniffing people's email/Facebook/bankaccount/whatever).
No amount of crypto theory is applicable to these sites because they're not interested in it.
Re: Auth secrets should always be LOCAL (Score:2)
PKI... How would you share it with your desktop and cellphone and Alexa? ("local" doesnt exist...) And make it work from cellphone web browsers?
Slashdot filter (Score:2)
Could we get all of the "accounts at X compromised" stories put into a dedicated section that we can filter out of the front page if we so desire?
I get that these are important to those people who are affected, but it's getting to the point where there's at least one, sometimes more, of these stories every day. There's nothing new to be said about the topic.