I'm CTO for Manwin Canada and ultimately responsible for YouPorn.
It's unfortunate that people are associating chat.youporn.com to the actual YouPorn.com site, but they are not affiliated at all. It was operated by a completely separate entity, which we've obviously closed as soon as we discovered it. The accounts on chat.youporn.com are different than the accounts on YouPorn. Though as was mentioned, it is probably that some have re-used the same username password combination that is highly unrecommended for all you folks out there (if you read Hacker News, you already know that).
As for password policies, I've been enforcing hashing of passwords ever since joining, though as we inherit a lot of old code and sites we correct issues such as that as we come across them.
I'll be around for a while, if anyone wants to ask questions.
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 security audit firm? There's plenty of value to in-house audits, but some kind of independent audit is probably a reasonable choice. You probably don't have PCI concerns (it's free, right?), but users might feel better about privacy otherwise. Just the existence of an account for a given user is probably an issue for some people, so even foolish things like using the same username on a porn site as on other sites could be a leak -- being able to verify that myhusbandinvirginiasportsfan is a valid user account on youtube would potentially make a divorce attorney very happy.
Would you answer general questions about the site/business, too? The whole porn tube thing seems like a big change in the industry (I was at SHOT Show in Vegas a few weeks ago, and stopped by the concurrent AVN event -- they really hate the tubes). I'm especially curious how you feel about the meta-tube sites (e.g. fantasti.cc) which seem to blatantly scrape youporn (and other tube) content. Preroll ads still show, but nothing else.
Hashing algorithms are not standardize across our network of sites yet. We use various methodology depending on what allows us to move fast and secure. You would be surprised to see the amount of moving parts there are.
We are currently in very close discussions with the 3rd party. In our official statement we purposely did not name them, we don't want to throw them under the bus. Of course we are reviewing all obligations.
We do deal with multiple security firms, and we regularly do security audits (both white and black box audits). We also deal with PCI, because we have paying sites as well, like Brazzers.
We can talk about the industry in general another time, but obviously we believe all types of sites can co-exist.
A single round of a hash -- salted or not -- is simply broken in 2012. When you can rent time on a bunch of GPUs on EC2 for effectively nothing, breaking the vast majority of hashes takes no work at all. PBKDF2 with a large number of rounds (10000 recommended), bcrypt, or scrypt are a requirement IMO.
There are about 252 trillion or 2^48 passwords consisting of 8 symbols drawn from (uppercase/lowercase letters + numbers + space). These are presently available in a downloadable lookup table which uses a compression method called 'rainbow tables' to store this information in just 350 GB, if I am reading these numbers correctly. There are similar lookup tables which include all 32 symbols accessible from the keyboard out to 7 characters, taking up 130 GB on disk. These speedups and compressions are made by large distributed computing projects, and would otherwise be out of the range of normal consumers -- but now that the lookup table has been generated, it can be pretty quickly queried, as I understand it.
Salting a hash is meant to stop precisely these attacks, and these numbers were taken for MD5 in particular from:
However this also gives us a bound on what's possible. A large project with 10,000 users trying to brute-force passwords can brute force all 2^48 of these, and store them in a highly compressed fashion, in however long it takes to make these things (months?). In theory, no password with under 48 bits of entropy is truly safe from someone with access to, say, government-scale computation.
What's possible for the rest of us? I can use Node.js to encrypt a typical password using PBKDF2(HMAC-SHA1) like so:
This takes 377 ms on my web server and calls SHA1 something like 2^18 times (twice for HMAC, 2^17 for the PBKDF parameter above), 255ms on my laptop. It's also a wrapper for an OpenSSL routine. So this should be about typical for C routines, and I should be able to do 2^20/s without GPU speedups. (That's 2^36 passwords/day.)
The above password 'sconesMultiply51' only has 40 bits of unpredictableness, so give me about two weeks, '0SGrf8KIZ', and sha1('0SGrf8KIZsconesMultiply51') and I can quite possibly find 'sconesMultiply51' by brute force on a laptop.
GPUs make things faster. This site:
reports doing sha1($pass.$salt) 80 million times per second on an older GPU (an nVidia GTS250). So they can get 2^26/s. If they're right, then they could hypothetically find 'sconesMultiply51' in under a day, as long as you reconfigured them to start searching words from a 10,000-word dictionary which might optionally be capitalized, rather than individual characters.
What's the absolute upper bound? Well, thankfully, the biggest public supercomputers are actually very well-known and published on top500.org. The absolute top of the line today is this beast:
It does 2^53 floating point operations per second. Assuming a hash is something like 100 or 1000 operations, you'd still have 2^43-2^46 tries per second. That's probably an upper limit on what your typical government can do, as well.
Lessons: (1) you'll be safe for the next 20 years at least if you just get used to
head -c 9 /dev/urandom | base64 | sed 's/+/_/g;s/\//-/g'
and the 12-character passwords that result. (2) you can give people about 16-20 bits of extra security if you use key stretching techniques, but that's about it.
The 3rd party sells their service, which is web-based chat application, to any company. Think of it as a company that offers hosted forums (SaaS model), but chats instead of forums. It allowed Youporn to offer a chat service to users, without us having to develop and maintain it. Again this decision was done before we took over.
Using chat.youporn.com is not that different than using ypchat.com, personally I would have preferred the latter for obvious reasons.
"...but they are not affiliated at all. It was operated by a completely separate entity"
Well if what you say is true, then it seems like they are affiliated and the CTO's above statement seems off. Of course you can be a separate entity and still be affiliated.
I would say "not affiliated" if said company was just paying them a flat fee per month to run their stuff on a subdomain. If they are, however, getting a percentage of revenue, it's a classic affiliate model.
I don't know the financial deal that is in place, but I don't see how it impacts the affiliation.
From my perspective the accounts are not shared, so you needed to register there to create an account. We don't share databases. Also, it is not our company and operates completely independent from us. This is what I meant by not affiliated. Hope that clears it up.
Appreciate your answer. Parts of your post make it seem like you have next to nothing to do with this; while other parts make it seem like you do have responsibility for this.
Also, it is not our company and operates completely independent from us.
Do you mean by this that the SaaS chat application deployed at chat.youporn.com is developed by a different entity to youporn? If so, then I understand the different entity part. But does that entity also own the users and serve its own TOS than you guys for chat.youporn users? If you are merely deploying a SaaS but have your own TOS and own the users, then it seems like while YouPorn may not be at fault for the technical goof up, but you are still responsible overall since the users belonged to YouPorn(not the parent entity).
Nothing personal, but is there something about the industry that causes you to be evasive and use weasel words? It doesn't seem controversial that giving a company a subdomain on your site implies an associative connection, not just "I suppose..." SRS Q.
No I wasn't, our company had no involvement with YouPorn at that time.
We spoke to the owners about the issue and they are really some of the nicest people we've met. They really did not have malicious intentions.
That issue brought the privacy flaw to the forefront, and certainly the adult industry pushes those limits. We always strive to respect industry best practices regarding privacy, especially around cookie handling. We constantly review privacy policies around the world.
I have a 50/50 chance of traveling through Montreal & Ottawa later this year. I'd love to buy you a coffee and pick your brain a bit about your tech stack and the IT challenges you've faced at YP. May I contact you?