Live data from Hacker News

Hack of Cupid Media dating website exposes 42 million plaintext passwords

arstechnica.com

11–20 of 168 posts

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#11
post #7

This is getting ridiculous. When are we going to see legislation enacted to take these people to task? Surely there is a case to be made that their negligence causes (or has the potential to cause) real harm to their users. We need a Saul Goodman to put together a class action.

> When are we going to see legislation enacted to take these people to task?

And how would you enforce this ? mandated paid audits provided by companies that have lobbyists and friends in Washington ? Enough with the laws, laws are not an answer to every problems. If there is harm , let the users sue, but stop with your laws...

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#12
post #8

Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…

I agree, trusting remote services (and the communication infrastructure in between) is naïve. Meanwhile, I use KeePass and generate a different key for each service.

I also use Keepass....but why the smeg do I need to do this? My browser should be deriving per-site passwords for me at a minimum

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#13
post #8

Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…

Realistically we need HTTP digest authentication [0] to use a better hash function then md5, and we need it to be deployed by websites.

[0] http://en.wikipedia.org/wiki/Digest_access_authentication

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#14

I can't get my head around how this still happens. I few years back I took over development of an old PHP website, which had a horrible code base (no framework or library, not even MVC). This site had around 30,000 users, all with plain text passwords. It took me all of a couple of hours to get the site using bcrypt. I'm not saying I'm some kind of super-rock-ninja-star developer, just that this is so easy to fix, ev…

Because of this:

If a site is using plaintext password often the owner asked for it. They wanted their users to be able to recover their passwords. And the dev didn't understand why this was a bad idea. They need to be educated, convinced and then convinced that the time you're about to spend on fixing this is more important than the 101 other things going wrong because the original dev wasn't very good. And isn't actually causing a single problem right now.

That also means that the password recovery function uses this code. Maybe there's an auto-user generator when you sign up for the newsletter. The email system obviously also uses that code. That also sometimes even means the password is stored twice, once in the framework's user mgmt tables and once in a user or person or the tblPRSN_UPDATED_OPTIMIZED_mc table. And just deleting that column might cause all sorts of other problems. Setting it null might cause bugs. Setting it empty string might cause a massive security hole as there's a login mechanism you haven't even found yet. (remember the dropbox breach?)

It's never a 3 hour job to fix unless you're very bad at estimating, are working on something extremely trivial or do a half-ass job, potentially introducing a far worse security hole.

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#15
post #8

Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…

Realistically we need HTTP digest authentication [0] to use a better hash function then md5, and we need it to be deployed by websites. [0] http://en.wikipedia.org/wiki/Digest_access_authentication

The trouble with digest auth is it requires the password or a usable representation thereof to be stored in recoverable form. This means that if you can get a dump of a site's database, you can use the stored credential data to authenticate to that site, which isn't possible when you store hashed passwords.

This is better than transmitting passwords in the clear, but worse than transmitting them over an encrypted link.

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#17

I can't get my head around how this still happens. I few years back I took over development of an old PHP website, which had a horrible code base (no framework or library, not even MVC). This site had around 30,000 users, all with plain text passwords. It took me all of a couple of hours to get the site using bcrypt. I'm not saying I'm some kind of super-rock-ninja-star developer, just that this is so easy to fix, ev…

Well they were lucky you fixed it.

There are loads of sites built year ago that just work so nobody is looking into the code base ever.

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#18
post #8

Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…

Realistically we need HTTP digest authentication [0] to use a better hash function then md5, and we need it to be deployed by websites. [0] http://en.wikipedia.org/wiki/Digest_access_authentication

Kinda. The important thing to note is that back in 1997, when the digest auth RFC was written, we recognised the hashing before going over the wire... and somehow we lost sight of that

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#19
post #12

Earlier quoted context omitted.

I agree, trusting remote services (and the communication infrastructure in between) is naïve. Meanwhile, I use KeePass and generate a different key for each service.

I also use Keepass....but why the smeg do I need to do this? My browser should be deriving per-site passwords for me at a minimum

LastPass has browser plugins that do this.

Edit: Additionally LastPass supports login to your LastPass account via password + OTP combination such as Google Authenticator and Yubikeys.

Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords

#20
post #8

Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing. Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide: https://en.wikipedia.org/wiki/Secur…

Realistically we need HTTP digest authentication [0] to use a better hash function then md5, and we need it to be deployed by websites. [0] http://en.wikipedia.org/wiki/Digest_access_authentication

Additionally, you'd need new browser APIs (AFAIK) to detect failed logins, render the login UI, etc. Otherwise, it's going to look out of place and confusing. Product managers are unlikely to accept the default browser/OS handling.

And digest auth means a DB dump has enough information to authenticate as a client, which is considerably worse for security if a server gets compromised.

Post reply on HN