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

71–80 of 168 posts

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

#71

Post by mazesc »

thatthatis wrote: post #60
raverbashing wrote: post #55

Earlier quoted context omitted.

well, you could even do it manually echo 'this is my pass' | shasum 3b0c5dc943cd30dcd2ca1ff760145f219d3ba3f3 And use that as the password. Of course, this is a very basic example, you should make it more safer by adding a salt and running more iterations. May be easier (and safer) than installing "One password" kind of software.

That doesn't quite work in the unfortunately common case of user password re-use. If your hash is constant and stored in plain text somewhere and that place gets hacked -- then your password at every site is compromised.

echo "this is my pass for $URL" | shasum

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

#72

Post by ye »

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…

What's the point of the key stretching on the client side, if your stretched key gets sent to the server and is stored in plaintext.

It adds no security.

Server-side salting and hashing is the answer.

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

#73

Post by nly »

bjourne wrote: post #51
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…

I agree with you that a technical solution is needed. Forcing developers to store passwords securely, experience shows it doesn't work. But how exactly would your solution work? If I work at a computer I haven't used previously, how am I supposed to authenticate to a site without using a password?

The first step in the SRP protocol is to retrieve the cryptographic salt from the server, so you're essentially free to roam.

This step has concerns of its own though... for one thing the request itself reveals that the username/id is valid, and if you cache the userid / salt pair on the client machine it's vulnerable to snooping by other people with physical access. There are some fairly straightforward tweaks that can be made to the protocol to work around these issues though, since the salt isn't sensitive. In fact, I'm pretty confident storing the salt server side can be eliminated.

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

#74

Post by jawr »

thatthatis wrote: post #53
fauigerzigerk wrote: post #24

Earlier quoted context omitted.

"The answer" doesn't exist and it never will. Everyone has to do their part. Services that store passwords in plaintext should definitely be publicly shamed, every single time.

A browser plugin that pre-hashes anything in a hidden text field (with a user secret key and the password origination domain) could mimic this as a layer on top of existing technology. It would have the obvious portability issues, and I'm sure other implementation issues.

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

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

#75

Post by vidarh »

nly wrote: post #73
bjourne wrote: post #51

Earlier quoted context omitted.

I agree with you that a technical solution is needed. Forcing developers to store passwords securely, experience shows it doesn't work. But how exactly would your solution work? If I work at a computer I haven't used previously, how am I supposed to authenticate to a site without using a password?

The first step in the SRP protocol is to retrieve the cryptographic salt from the server, so you're essentially free to roam. This step has concerns of its own though... for one thing the request itself reveals that the username/id is valid, and if you cache the userid / salt pair on the client machine it's vulnerable to snooping by other people with physical access. There are some fairly straightforward tweaks that…

> This step has concerns of its own though... for one thing the request itself reveals that the username/id is valid

Does it have to? Can you not have an implementation that always responds with a fake salt if the username is not valid?

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

#77

Post by adamtulinius »

jawr wrote: post #74
thatthatis wrote: post #53

Earlier quoted context omitted.

A browser plugin that pre-hashes anything in a hidden text field (with a user secret key and the password origination domain) could mimic this as a layer on top of existing technology. It would have the obvious portability issues, and I'm sure other implementation issues.

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".

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

#78

Post by raverbashing »

thatthatis wrote: post #60
raverbashing wrote: post #55

Earlier quoted context omitted.

well, you could even do it manually echo 'this is my pass' | shasum 3b0c5dc943cd30dcd2ca1ff760145f219d3ba3f3 And use that as the password. Of course, this is a very basic example, you should make it more safer by adding a salt and running more iterations. May be easier (and safer) than installing "One password" kind of software.

That doesn't quite work in the unfortunately common case of user password re-use. If your hash is constant and stored in plain text somewhere and that place gets hacked -- then your password at every site is compromised.

Yes, you need to add a salt, it can be the URL (and something else added)

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

#79

Post by nyrina »

onion2k wrote: post #6
mfkp wrote: post #4

Had to look it up - unrelated to okcupid. For those interested, here's a list of their web properties: http://www.cupidmedia.com/services.cfm

Ironically, one of their sites is "OnlineDatingSafetyTips.com".

I don't think that is the kind of safety they are talking about

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

#80

Post by dagw »

jheriko wrote: post #61

maybe i am just stupid, but how are password managers secure? i've seen people using them, and if i were of a less honourable persuasion i could abuse that quite easily... on the other hand, its impossible for me to steal information from out of their brain (so far at least).

"how are password managers secure"

Because now you need to steal two things. My password file and my password.

Now admittedly the one weakness is that once you have both those things you have access to all my passwords, but on balance I believe it is an acceptable compromise.

Post reply on HN