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

31–40 of 168 posts

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

#31

Post by relix »

jiggy2011 wrote: post #27
mattmanser wrote: post #14

Earlier quoted context omitted.

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…

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.

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

#32

Post by TomGullen »

danenania wrote: post #30
markdown wrote: 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.

Yes, the government would surely do a great job legislating development standards. Just look how terrifically they've handled software patents.

Free markets currently doing a pretty awful job of it as we keep learning. Perhaps some government legislation would help.

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

#33

Post by revelation »

richardwhiuk wrote: post #13
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…

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

Realistically the problem with that isn't even MD5, it's the modal popup that hasn't changed in any browser since 1999.

It's so unbelievably popular, Chrome copied the behavior despite not existing in 1999. It's all over mobile, too...

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

#34

Post by chalst »

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.

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-crypto-library

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

#35

Post by l0gicpath »

stfu wrote: post #5

Just a random question: Is there anything that gives companies incentive to prevent such hacks? It seems that there is no consequences at all, except for some loss of reputation in tech community. Is there a way to put legal pressure on tightening up security?

You are looking at necessity products built by large corporations whose products are usually regarded as the best of breed in the market.

If you are a designer for instance, you'll most likely come to depend on Adobe Photoshop. That means at some point you've created an account. Adobe got breached and your data got leaked, you'll likely whine a little about it online but unless you are willing to:

- shift your work and relearn a new tool than Photoshop

- navigate your way around closing your account (with the assumption that your data is actually deleted after account closure) which is rather hard in most cases, no one likes losing users.

Then you'll likely just suck it up, do what you can and hope for the best.

On the other hand, you got small time (but growing - not web-scale yet-) services/products that can't really afford losing a large number of users. Those would worry most about security. Ironically, they'd stay off the grid for long enough and wont become attack targets until they make it big.

But that's just really the security industry, no system is 100% secure. And you never know if you've tightened your security enough until someone drills a hole. Then you patch it.

Any self respecting corporate will have a security auditing policy. The so called white-hat hackers or pen-testers. Good companies will run security audits every now and then in hope to discover new security holes introduced by software updates, system policy changes...etc.

As for legal pressure, it depends on what we are talking about. If you are a payment processing company then any data breach is a violation of your PCI compliance, which leads to a lot of bad PR and legal consequences.

If Facebook got breached and data was exposed, I doubt there is anything in the law that reacts to such issue. Unless someone sues Facebook for damages, then that's a whole different ball game.

The incentives are there for any business of all sizes. Legally? It depends. It's those schmucks that screw us all, plaintext passwords and shit.

Edit: Fixed formatting.

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

#36

Post by jiggy2011 »

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.

Maybe simply emailing the password still has a higher conversion rate than the one time link, for example if the user does not see or understand the link or perhaps they want to login later when their email is not open.

It can be difficult to argue for security in cases where even small % of short term revenue might be affected.

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

#37

Post by nly »

NateDad wrote: post #26
Zombieball wrote: post #19

Earlier quoted context omitted.

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.

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

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

#38

Post by modoc »

nly wrote: post #12
facorreia wrote: post #10

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

Safari on 10.9 does this.

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

#39

Post by nly »

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.

Yes, I love trusting the keys to all my accounts to one corporation.

Less tongue-in-cheek, would you trust Facebook login for banking?

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

#40

Post by jacques_chester »

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…

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