YouPorn passwords available for download, thousands of users exposed

Post by jrockway » Thu, Feb 23, 2012, 2:24 AM UTC

spindritf wrote: post #58

jrockway wrote: post #30

Earlier quoted context omitted.

What baffles me even more is how some people actually whip out their credit card and give the digits to a porn site. Why? Most of the big porn studios are as trustworthy as any other Internet business of the same size, and if your credit card number is misused, you're not liable for the charges anyway. Porn popularized selling DRM-free content for money long before Louis CK made it popular. Porn actors need to pay th…

> Why? Most of the big porn studios are as trustworthy as any other Internet business of the same size The probability of a leak may be similar but the downside isn't. It's no problem whatsoever if your name is linked to cheapprogrammingbooks.com, you cancel the card, get a new one. The situation is somewhat different for spermgarglingteens.com.

Post by NelsonMinar » Thu, Feb 23, 2012, 2:51 AM UTC

pyre wrote: post #65

NelsonMinar wrote: post #35

Top 10 domains: 1469 yahoo.com / 1071 hotmail.com / 882 gmail.com / 205 hotmail.co.uk / 178 web.de / 136 gmx.de / 127 aol.com / 116 hotmail.de / 115 live.com / 104 hotmail.fr Top 10 passwords: 110 123456 / 75 123456789 / 30 12345 / 23 melinda / 19 fuck / 18 1234567890 / 17 Nightmare / 16 allzen / 15 password / 15 anal That's of about 6400 records.

I'm curious about these: 23 melinda 16 allzen Seems odd that so many people would end up with those passwords. Maybe these represent multiple accounts by the same person?

Post by pjscott » Thu, Feb 23, 2012, 4:06 AM UTC

uxp wrote: post #11

pjscott wrote: post #2

How many sites need to be humiliated like this before people learn to hash passwords with something like bcrypt? It's like two damn functions. You just call them! It's so easy that even a baby squirrel could do it! There is no excuse. Until then, I hope everyone is using a throwaway password for accounts that can be non-disastrously stolen, and using strong unique passwords for the important ones.

Based entirely on the format of the data that was publicly accessible, it looks like this data, including usernames and passwords, are raw $_POST server variables spit out in a debug log. All the hashing and encryption in the world can't protect you against saving the data to disk, above your webroot, in plain text before you hit your security component. This was pure programmer error, a form of ignorance, but not ne…

Post by daeken » Thu, Feb 23, 2012, 11:56 AM UTC

rplnt wrote: post #76

rdl wrote: post #46

Earlier quoted context omitted.

Thanks for showing up here! By hashing, do you mean current best practice (bcrypt, scrypt, or possibly a pbkdf with high work factor), or something easily brute forced like MD5 and SHA1. There are issues with migration if you're doing the latter, but not a big deal. Do you have any contractual recourse against the chat provider? Have you considered including such terms in future contracts with partners? Do you have a…

What is wrong with salted SHA or even MD5 for that matter?

Post by brodd » Thu, Feb 23, 2012, 1:26 PM UTC

ars wrote: post #48

Cushman wrote: post #25

Earlier quoted context omitted.

"Use bcrypt" is the answer to all those things. Bcrypt includes a salt, which is stored along with the method in the hash string. Hashing is not the same as encryption, so there is no key involved.

If you are using PHP then do this: $salt = '$2a$08$' . $random_data; $hash = crypt($password, $salt); $random_data is 22 random letters from A-Za-z0-9.= (16.5 bytes) (08 is the cost factor - you can change it, but 8 seemed reasonable in my tests.) If you google bcrypt and php you'll find a very complex and large class for doing this. It's no longer necessary - current versions of PHP have it built in.