Anyone know where to find the password dump?
While this might sound not so appropriate at first but I too would like to have the dump. Can result in some interesting password research.
Hack of Cupid Media dating website exposes 42 million plaintext passwords
151–160 of 168 posts
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#152Earlier 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
Kinda. The important thing to note is that back in 1997, when the digest auth RFC was written, we recognised the hashing before going over the wire... and somehow we lost sight of that
The browser implementers completely punted on making HTTP authentication usable: there's no friendly way for a user to logout, for the server to force a logout, for the user to change a password, etc. All of these were well known and discussed from day one but they weren't seen a priority by any vendor and most web developers went with usability over security.
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#153Earlier quoted context omitted.
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.
Security is all about pragmatism: is it more likely that Facebook / Google will be hacked and not deal with it quickly or that users will react to incessant password nagging by using weak ones? When someone's account is compromised, is it better if they have to change one password or hundreds?
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#154What 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…
This is a good argument for unique passwords, not for weak passwords. Weak passwords only "make sense" if you really don't care whether your account is compromised due to a very weak password.
This is 100% true in my case. If I value the service, it gets a unique password. If it's Gawker Media, well here's a hash for 12345 and have fun with it.
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#155Earlier quoted context omitted.
"Up next on VH1's Where Are They Now? , Alice and Bob!" Alice: At the time I thought Eve was the only one I had to worry about. Little did I know, Carol would be the one who'd really replace me in the end. Edit: Hmm, downvoted. I guess humor isn't welcome here?
Unfortunately, no.
A bit of transparency: Before the edit I received one downvote. After I received 5 upvotes, which is on the higher end of most of my comments. Either I reacted prematurely, or calling it out reversed the perception bias to the positive. I think it's some of both, as the joke really wasn't funny enough to warrant the score.
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#156Earlier quoted context omitted.
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?
Yes, in the same way that simply using scrypt would.
But, of course, the point isn't that SRP is a weak construction. The point is "client side stretching", whatever that was intended to mean, has nothing to do with the problem of losing a database of password "verifiers", be they plaintext, salted hashes, password hashes, or SRP v-values.
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#157Earlier quoted context omitted.
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.
Oh, neat. I'm happy to have a number to file away. Thanks!
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#158Before 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.
I propose a scarlet letter "P" (for plaintext).
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#159Earlier 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.
This is (hopefully) a problem that platform owners can solve for us, and if they do I'll love them for it, but they very likely won't take it on.
Apple/Google/Microsoft can bake in cross-device syncing into the browser/OS and apply this sort of thing on form auto-fill.
It'll break down when:
a) Hashes don't meet site-specific password requirements (too long, missing special characters, etc.)
b) Sites store passwords in plaintext and you forgot your password and ask for them to email it to you (user: What the hell is this garbage of text, I didn't type this in!)
Unfortunately the above problems usually occur on sites where you need this most, and are very hard to solve, and so this problem is therefore unlikely to be solved "neatly" by anybody big.
Re: Hack of Cupid Media dating website exposes 42 million plaintext passwords
#160What 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…
You're not completely in the clear if you still use the same username throughout the web or as the start of your email address. If your account gets compromised on a site that allows users to make public posts (comments, articles, whatever) your online identity is now linked to whatever crap the compromiser posts under your username.