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

51–60 of 168 posts

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

#51

Post by bjourne »

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?

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

#52

Post by jve »

nly wrote: post #37
NateDad wrote: post #26

Earlier quoted context omitted.

LastPass is awesome.

Installing lastpass on every machine I happen to stroll by and want to use isn't the cleanest of solutions... and I shouldn't have to trust my keys to one closed, proprietary application. With a standard protocol at least I'd have a choice about my client. There are also peripheral issues with password databases, like the fact that they make the mere fact that you're using one transparent to anyone investigating your…

You can ofcourse log in to lastpass.com on any other machine you are sure doesn't have a keylogger (well they provide virtual keyboard also if thats the case).

But ofcourse, that's matter of trust, even when they say that data is encrypted client side and they store only blob of gibberish. However I feel so relieved by using LastPass - not having to worry about remembering yet another password.

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

#53

Post by thatthatis »

fauigerzigerk wrote: post #24
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…

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

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

#54

Post by ZoFreX »

Cthulhu_ wrote: post #45
jiggy2011 wrote: post #29

Earlier quoted context omitted.

The problem is that "publicly shamed" means "shamed amongst security geeks". Most websites main demographic is not security geeks.

I dunno, things like this make their way to more mainstream media too, making "the general public" more conscious of security, and making them wonder whether their passwords will be secure at parties they leave them at.

The spin in mainstream media always puts the blame squarely on the hackers, and in my anecdotal experience typical users have no interest in the argument that the companies that were hacked are to blame.

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

#55

Post by raverbashing »

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.

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.

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

#56

Post by jacques_chester »

nly wrote: post #49
jacques_chester wrote: post #40

Earlier quoted context omitted.

This is an is/ought fallacy. As professionals we don't get to propose the ideal universe as the solution to the problems of the actual universe. We have to take what we can get right now.

And that's a false dichotomy. Are you saying we should dismiss dangerous flaws in the trust model, just because we have some workarounds for bad industry practice, and can 'make do'? because I'm not saying we shouldn't advocate strengthening existing databases right now. To me, the two concerns are completely separate.

The is/ought fallacy isn't about saying that the actual world and the ideal world are mutually exclusive; that you can't get to the ideal world from the actual world.

It's that dismissing actual options because they are not as good as hypothetical options is fallacious reasoning.

It's about taking the actual world seriously, on its own terms, without getting tied up in knots about the parameters of the ideal world.

Right now we don't live in a world with a better browser security model. Regardless of whether any one of us individually argues for such a world, the current world is where our professional duties must be discharged.

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

#57

Post by kawsper »

relix wrote: post #31
jiggy2011 wrote: post #27

Earlier quoted context omitted.

It's quite possible the dev knew it was a bad idea and maybe even argued against it but was told to implement it this way anyway. The problem a dating site probably has is people who sign up accounts and then stop using them. They want to send these users reminder emails in the hope that some of them re-engage. Problem is that some of these users have probably forgotten which password they use for that website, and s…

I include an "Instant Login" link in each mail so the users don't need to remember their password. It contains a unique time-sensitive token to identify the user and instantly sign them in (much like a password reset). I learned this technique from OKCupid, so no idea why they still had plaintext passwords.

After how much time will the token expire?

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

#58

Post by MarkMc »

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?

I think the idea is that the browser would implement SRP. That means you would still type a password into your browser, but it wouldn't be sent to the server. Instead, the browser and server would authenticate you by means of exchanging specially-designed hash codes.

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

#59

Post by rmc »

tschellenbach wrote: post #22
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 about Facebook login (or other oauth based systems)? Seems to me this solves most of the problem.

Until the site that you use for OAuth gets hacked.

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

#60

Post by thatthatis »

raverbashing wrote: post #55
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.

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.
Post reply on HN