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

141–150 of 168 posts

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

#141

Post by tedunangst »

nly wrote: post #89
jacques_chester wrote: post #56

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…

What would a sample query look like with a password column?

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

#142

Post by aestra »

sdoering wrote: post #41
markdown wrote: post #25

Earlier quoted context omitted.

> And how would you enforce this ? ... mandated paid audits No, that would be quite silly and wouldn't work. It could simply be reactive rather than proactive. When an incident occurs where sensitive user data is exposed, simply launch an investigation into whether there were "adequate" protections in place. If it is found that sensitive data was stored unencrypted, for example, put the directors of the company behin…

Even more simpler: If "adequate" protections are missing: Pay every breached user $10. That way such a breach gets a hefty price-tag and devs/PMs could argue with management, that it is economically feasible to implement these measures. I know of a PM, that tells devs, that report security-problems inside his product, that they should not care, but instead finish "that news shiny little thing" and that that is their…

It would be next to impossible to track down the majority of users, and I doubt each user would like to fork over more personal info for just $10. Paid money would be very small vs amount of accounts.

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

#143

Post by tedunangst »

tptacek wrote: post #122
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 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 bcryp…

For reference, iirc last time I ran the numbers, SRP brute forcing has a work factor of 1000 compared to a single round of md5. Aka, not enough.

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

#144

Post by Jach »

raverbashing wrote: post #135
Jach wrote: post #109

Earlier quoted context omitted.

If you use an actual bash script instead of a one-liner, and you can do things like 'silently' read in the password with `read -s` in the standard *nix convention, even read it twice to avoid mistyping your master key and temporarily locking yourself out of an account you just created.

Here's a tentative crude solution http://pastebin.com/MuV8vtcR you can pass a "salt" as the first argument as well (it will merely be concatenated with the password)

You should quote your vars in the if check, otherwise it doesn't handle spaces very well. (And really the master key should be a master passphrase.)

A few years ago I whipped this up: http://www.thejach.com/public/pw2 (I don't recommend other people use it but it works for me.) I type in something along the lines of "my secret passphrase ycombinator.com". It doesn't do hash iteration and uses the hash as a seed to Python's RNG which I use to get random bytes and then have a password character-space of any printable character -- it also outputs an alpha-numeric version along with different string sizes to handle those dumb sites that put restrictions on your password.

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

#145

Post by nitrogen »

tptacek wrote: post #122
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 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 bcryp…

Is there a variant of SRP that would provide the same level of protection against a server hack as bcrypt?

Edit: it looks like it should be possible to replace H() in SRP with bcrypt or scrypt. Wouldn't that mitigate brute forcing from server hashes?

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

#146

Post by aestra »

danenania wrote: post #69
TomGullen wrote: post #32

Earlier quoted context omitted.

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

All legislation would do is put a big layer of ineffective bureaucracy between developers and getting work done. Get the government involved and it won't be long before you need to fill out 15 forms and hire a lawyer to put your weekend project online. Is that the kind of internet you want?

Yeah, all those building codes do is put a big layer of ineffective bureaucracy between the people who architect and do construction and getting work done.

Yeah, all those sanitation codes do is put a big layer of ineffective bureaucracy between the people prepare food and getting work done.

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

#148

Post by nitrogen »

revelation wrote: post #33
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

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

I wonder if the original reason for using a modal OS-level popup was to prove that it's not a fake prompt displayed by a malicious site.

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

#149

Post by nitrogen »

jve wrote: post #52
nly wrote: post #37

Earlier quoted context omitted.

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.

...(well they provide virtual keyboard also if thats the case).

If you assume a key logger, you should also assume a mouse logger that captures a partial screenshot for every mouse click, as well as the possibility of capturing the contents of password fields (malware in the Windows 9x era would iterate through all OS widgets to find password fields and save their contents).

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

#150

Post by diminoten »

bigdubs wrote: post #132
diminoten wrote: post #126

Earlier quoted context omitted.

Keylogger.

Sure, but if you have that level of access to the machine, what's the point you're making?

I dunno, he asked a question and I answered it. I'm making no point.
Post reply on HN