Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hack of Cupid Media dating website exposes 42 million plaintext passwords

arstechnica.com

Post reply on HN
Print view View original

91–100 of 168 posts

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

#91

Post by maxtaco »

nly wrote: 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…

How does SRP help? With SRP, you still have a server-side brute-forceable table of password hashes. The server stores v = g^x, x = H(s, p), for each user, where s is the salt and p is the password. g is known to the server (and hence the attacker), so if the attacker downloads the database, he can go through the dictionary and brute force. If you're rolling out SRP, you ought to use scrypt for H.

Edit: and BTW, Cupid.com has nothing to do with OkCupid. They were the cause of much confusion throughout our history. We'd tell people to sign up for OkCupid, and they'd go to Cupid.com. Eventually, Cupid.com had to say, in their radio ads, "Not OKCupid.com, go to Cupid.com!"

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

#92

Post by Keyframe »

mattmanser wrote: post #14
MattBearman wrote: post #3

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 ac…

Most of the times I think it's due to owner and/or developer wanting to harvest passwords. I've seen it happen.

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

#93

Post by chalst »

nly wrote: post #44
chalst wrote: post #34

Earlier quoted context omitted.

It solves the problem with offline password cracking, but it introduces the need to trust a third party. Since the client side of SRP can be implemented in Javascript [1,2,3], there's not really much in the way of compelling reasons not to use it. [1]: There's a client in the SRP bundle at http://srp.stanford.edu/download.html [2]: https://github.com/symeapp/srp-client [3]: https://github.com/clipperz/javascript-cryp…

One of the key aspects of SRP is it provides mutual authentication. The server is considered untrusted until authenticated. If you run it in Javascript you lose the benefits it has over simple challenge-response client authentication. TLS-SRP could replace ordinary CA based server authentication, but I think there's a middle ground somewhere. Both are complimentary. CAs should be authenticating servers to my browser…

This isn't quite right: you still keep the benefit that the server in no sense has a copy of your password, and it is publically visible what the program is that implements the client-side authentication.

That said, I agree that there are strong benefits to having support for SRP in the browser.

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

#94

Post by colanderman »

andrewaylett wrote: post #15
richardwhiuk wrote: post #13

Earlier quoted context omitted.

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 lin…

Your point is correct but AFAIK your facts are incorrect.

Digest authentication can indeed store the password in hashed form. The problem is the the client doesn't need the plaintext password; this hashed form suffices.

See " rel="nofollow">http://en.wikipedia.org/wiki/Digest_access_authentication#Ad....

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

#96

Post by thatthatis »

adamtulinius wrote: post #77
jawr wrote: post #74

Earlier quoted context omitted.

Awesome idea, should randomly salt them for users who insist on using the same password for different sites.

"i created my account on machine x, now i can't log in from machine y".

That being the obvious portability issue.

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

#97

Post by sillysaurus2 »

nly wrote: 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…

It's interesting that no one's pointed out that SRP is trivially breakable by having the client send zero as its "A" value.

Of course, you can guard against that particular case. But the point is that SRP has pitfalls, just like every other solution. And those pitfalls aren't well known; the Wikipedia pseudocode makes no mention of that exploit, for example.

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

#98

Post by thatthatis »

jawr wrote: post #84
adamtulinius wrote: post #77

Earlier quoted context omitted.

"i created my account on machine x, now i can't log in from machine y".

Might be an extreme comparison (beg your pardon if I'm being naive), but it's a similar hinderance to using SSH keys. Carry it around on a USB key, or deal with the security outweighing convenience.

I like that. Could even be coupled with a portable browser.

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

#99

Post by thatthatis »

livnev wrote: post #88
adamtulinius wrote: post #77

Earlier quoted context omitted.

"i created my account on machine x, now i can't log in from machine y".

What about determining the salt from the domain for the given login? (perhaps slightly more refined than that to mitigate cases like *.google.com)

I think that's right. It would also need some ability to add mappings like "when I log in from gmail.com, hash like it is google.com"

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

#100

Post by andrewaylett »

colanderman wrote: post #94
andrewaylett wrote: post #15

Earlier quoted context omitted.

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 lin…

Your point is correct but AFAIK your facts are incorrect. Digest authentication can indeed store the password in hashed form. The problem is the the client doesn't need the plaintext password; this hashed form suffices. See " rel="nofollow">http://en.wikipedia.org/wiki/Digest_access_authentication#Ad... .

That's what I meant by 'a usable representation thereof' -- sufficient data for a client to be able to use it to authenticate.
Post reply on HN