Live data from Hacker News

Hack of Cupid Media dating website exposes 42 million plaintext passwords

arstechnica.com

121–130 of 168 posts

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

#121

What this story shows is that sometimes '12345' makes sense as a password - i.e. when credential security doesn't matter to the user. If I use '11111' to sign up for a onetime visit to a website, then there's no nexus with my online banking account other than an email address - assuming even the most feeble attempt at picking a 'secure' password for my banking. This is why it is often silly when articles condemn user…

Use a password manager that generates a random password for every site.

Providing strong passwords on throw away accounts provides useful information to an attacker - I.e. that I am using password manager "foo". If "foo" is comprised, then all my passwords generated from it are at risk.

To put it another way, where there is no reasonable chain of trust, I provide useless data for determining my strategy where there is a reasonable chain of trust. Revealing '11111' does not improve the probability of an attacker generating my bank password.

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

#122
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 flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.

The math for the brute force attack on SRP verifiers is slightly more elaborate than that of a salted hash (it involves a modexp), but is significantly cheaper than bcrypt. Using SRP is, from the perspective of a compromised server, worse than using bcrypt.

You may have become confused about SRP because Thomas Wu goes through some effort to explain how SRP is resistant to dictionary attacks. If so, you've mistaken which specific dictionary attacks he was talking about: previous challenge-response protocols were dictionary attackable off the wire, meaning that a passive attacker could grab the challenge-response sequence and crack that as if it was a password hash.

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

#124
post #89

Earlier quoted context omitted.

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. R…

The false dichotomy I was referring to isn't the 'introduce bcrypt' vs 'introduce a new model' thing, those things clearly aren't mutually exclusive, it's that you inferred that me pushing for one means that I'm totally against the other in the present day. In any case I have no desire to join a thread about fallacious reasoning and semantics. > Regardless of whether any one of us individually argues for such a world…

If that column type existed, it would be a database-resident implementation of scrypt.

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

#126
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).

I've used 1Password (a popular password manager for the Mac) for several years now. How could you "quite easily" hack those passwords, assuming that's what you're implying?

Keylogger.

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

#128

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…

Sure, it's not hard to use bcrypt for passwords. It's also not hard to make your login forms use https, or to do weekly backups, or to use source control, or to keep Wordpress up to date. Yet many many websites/apps/companies do not get these right.

The barrier is not difficulty. The barriers are lack of time to spend on infrastructure/security improvements, lack of motivation, and distraction due to new feature requests.

Of course forgoing these things will bite you in the end, but this is the internet age; people don't tend to plan that far in advance.

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

#129
post #116

> Making matters worse, many of the Cupid Media users are precisely the kinds of people who might be receptive to content frequently advertised in spam messages, including male enhancement products, services for singles, and diet pills. Oh wow. So Internet dating users are generally stupid, under-endowed, desperate and overweight?

I was blown away this was included in the article. There's no citation, no explanation or anything. It's just blatant.

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

#130

Earlier quoted context omitted.

Use a password manager that generates a random password for every site.

Providing strong passwords on throw away accounts provides useful information to an attacker - I.e. that I am using password manager "foo". If "foo" is comprised, then all my passwords generated from it are at risk. To put it another way, where there is no reasonable chain of trust, I provide useless data for determining my strategy where there is a reasonable chain of trust. Revealing '11111' does not improve the pr…

>Providing strong passwords on throw away accounts provides useful information to an attacker - I.e. that I am using password manager "foo".

What? The attacker could infer:

* that you consider this account to be valuable and have created your own strong password for it.

* that you are a security conscious individual and keep a list of hand-generated passwords written down in a safe by your desk.

* that you may be running one of any number of password managers.

... in other words, it tells the attacker nothing.

That's not to say that using a junk password for a junk account is bad, just that your logic doesn't follow.

>Revealing '11111' does not improve the probability of an attacker generating my bank password.

Neither would me revealing my password for a throw-away service is "Sfx16tJ{=DK=x4A0v". What can you infer about my bank password from that?

Post reply on HN