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 necessarily a sign of incompetence.
Besides "use bcrypt" I've never really seen decent guidance on how to actually store passwords (what sort of salt to use, where to store the salt, if and where to store the hash method, how/where to store the key, etc).
"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.
$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.
I'll write one for you right now, because it really is as simple as I made it sound. I'll use the API from py-bcrypt here, but they're all pretty much the same. When a user gives you their password for the first time, here's what you store in your database:
Store hashed_password in your database for later. Then, when a user tries to log in, they will tell you their password. You'll need to check that it matches the hashed_password value you have stored. Here's how:
if bcrypt.hashpw(password, hashed_password) == hashed_password:
print 'Password is correct!'
else:
print 'Wrong password.'
That's all there is to it. The bcrypt library handles everything else. It is this simple because if it weren't, people would mess it up.
Hah, you're right. It's practically impossible to generate passwords in such way that they will give hashes differing by only a byte. Sorry, I see timing attacks everywhere.
This is actually a very good advice, especially for people like me who have hard time visualizing how complex things work. For example, when I tried to understand what the meet-in-the-middle attack is, and couldn't, it was incredibly helpful to implement it (https://gist.github.com/1062437). Then I understood.
> 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.
Why even bother with the distinction. Use a unique password for every login. Use something to manage your passwords. If someone is unwilling to generate a password for an unimportant site, they're probably also too lazy to properly generate unique passwords for sites that matter.
Okay, let's say you have to integrate with a third party product that can only deal with passwords in normal crypt(). What do you do then? (Rewrite third party product is not a valid answer).
What if you're integrating with something like a Windows VPN w/RADIUS, which needs the plaintext password?
Bcrypt, while trivial for many applications, is not the answer to everything.
im so glad you noticed this, because it got me laughing but i couldnt decide if it was on purpose or not either! A good joke on words makes the world a better place.
I was thrilled on the self-describing appropriateness of the term "double entendre" in this context until I found that "entendre" didn't actually mean "enter" in French. If it would, the term itself would be hilarious.
Why would anyone sign up for a porn site with their main email address? What baffles me even more is how some people actually whip out their credit card and give the digits to a porn site.
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 their rent too.
> 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.
And all this after all the press about them moving their entire stack to Redis etc etc. How can a company achieve such an epic technical feat and have shitty password hashing?
Everything was on http://chat.youporn.com/tmp/ completely open to the public so this is an even bigger screw-up than the fact that they didn't hash their passwords.
Unfortunately there are only 4800 unique users of total 6000 in pastie, a lot of dups. So recent arstechnica statistics, especially tag cloud by Ashkan Soltani, is not very accurate. It was very strange to discover generated '3kpm1858' password as popular. Check it here http://pastebin.com/f7MUMw6t
This has been passed around a certain anonymous messageboard for the better part of a week now, i'm surprised sophos has taken this long to write anything about it!
I don't understand how this makes it to Top News. I think at this point we are all well aware that no user-password store is impenetrable or invulnerable and porn websites would hardly be an exception. If you do not know by now that you should not be using the same password across multiple accounts, it seems like there is little hope. There is no lesson to be learned here. Is it not an implicit assumption that if you subscribe to a porn website someone is mostly likely going to find out one way or another?
1. Don't reuse passwords.
2. Don't subscribe to porn sites if you have something to lose from someone finding out.
It was actually the passwords to YP Chat, not Youporn itself. The Yourporn guys are pretty reasonable engineers and sysadmins, from what I've seen, and manage user passwords correctly.
Personally, I think in 2012, if you're not using a password manager to generate and manage unique, strong passwords per site, especially for "sketchy" stuff like porn sites, you're already doomed.
Also, Presidents Day and other minor useless holidays are great times for annual rituals like tracking down and changing any legacy shared passwords you may have. Don't wait for a breach!
The sad thing is, people don't use password managers out of laziness despite the fact that it actually speeds up all of these processes. One password unlocks it, one click to login to any of my sites with strong, secure, unique passwords. Autofills out registration forms and generates a unique password for me. It's faster than me having one memorized password.
Yet, friends and HN hackers alike have scoffed at my attitude which is roughly the same as yours. If you're blindly trusting sites with a non-unique password, it's only a matter of time.
(edit) To get ahead of the repeat replies, LastPass syncs across browser extensions, encrypt/decrypts locally, can be accessed from any browser even without an extension and has mobile apps. I've been using it for probably two years now and I've never not been able to access an account even when using all varieties of guest computers, iPads, etc.
I don't use a password manager because I don't always use the same computer. As a student I use a number of different machines on campus. A password manager would be extremely inconvenient.
I do, however, use a simple templated password. By including a few unique characters (following an easy to remember formula from the sites domain name) in an already strong base password, I can use dozens of unique passwords without any special environment.
There are several options which use remotely-saved, decrypted-in-browser password safes. You're still vulnerable to keyboard logging if you're using random systems/hardware. Accessing secure services you care about from multiple locations is not a good security practice.
If you carry a smartphone, there are several password safes available for these as well.
Clipperz (web-based) and KeePassDroid work for me.
On my primary systems, a simple text-based database GPG encrypted.
Your password template may or may not be good practice. From random cracking, probably safe. If someone takes a particular interest in you and has prior knowledge of your scheme and several revealed examples, other passwords may become discoverable.
The thing with password managers is that the most convenient ones store your data in a server somewhere. And that opens up more issues than it solves.
For the ones that store information in a local file, that could work. But then a lot of the mobility is lost, even if you use something like Dropbox (you are not going to sync behind a corporate firewall, for instance). At least my brain is attached to my head and is very portable, I just have to remember the damn things.
I answered the other person that replied. LastPass syncs across browser extensions, you can access your data from their website, it's all encrypted/decrypted locally and there are mobile apps so you can always access them securely even if you don't trust the guest computer.
I really like 1Password (but I use only macs for low security laptop/desktop stuff) -- the browser extension is great, and the iOS apps sync over wifi or dropbox.
The one thing I'm waiting for is iCloud integration. If they don't provide iCloud integration, I'd consider other options (including trying to roll-your-own, maybe using their extensions and spoofing the IPC)
It really needs to become the default at account creation.
I'm not sure how best to make it part of the site sign up process on the server side. The other hassle is you now really want to also link mobile platforms, so unless you're all apple, it's kind of tricky. You could possibly do a web-based password manager instead of something local (there are a few options), or if you're all-apple, 1Password (which doesn't even work perfectly on iOS).
The other way is to just move everyone to Facebook Connect or other third-party identity services, but there are a bunch of problems with that. If there were a single-signon provider which were only single signon, vs. profiles and all the other stuff, it would be more acceptable, but even then, just linkability of all your accounts is a security and privacy compromise, as well as being a single point of attack and failure.
I'm going to guess that there's a significant subset of YPChat users who also created YP accounts and also used the same login credentials for both...I mean, how many users who are savvy enough to create multiple-logins/passwords for a site and its chat subdomain would even create an account (one linkable to their identity) on YP in the first place?
Bonus: it appears YouPorn has no way to change your password, nor any way to change (or even see) the email address that is associated with your account.
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.
I suppose at some point the old owners did want to make that association. That deal was in place since 2008, we've been managing it for less than a year now.
We've been focusing on the rewrite of the main site and are now cleaning up all the secondary dependencies.
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.
Yes we are identifying which ones are affected. Due to changes over the years of how account information was handled, we want to be extra sure we are identifying the proper accounts, if any.
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:
http://tbhost.eu/rt.php?algorithm=2
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:
http://www.insidepro.com/eng/egb.shtml
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:
http://i.top500.org/system/177232
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.
How does that work? Who assigns the DNS values for chat.youporn.com? Moreover, youporn.com and chat.youporn.com actually point to the same IP address, namely 31.192.116.24.
There must be some level of affiliation then, right?
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?
Were you the CTO at YouPorn back in 2010, when the company abused a flaw (css sniffing) in web browsers that allowed your company to covertly determine what other porn sites users had visited? See:
http://www.forbes.com/sites/kashmirhill/2010/11/30/history-s...
Do you think that it was reasonable behavior to engage in without telling your users?
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.
"...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).
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.
89 comments
[ 3.2 ms ] story [ 159 ms ] threadUntil 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.
Nice catch, by the way.
(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.
https://gist.github.com/1053158
Edit: I'm wrong, sorry.
(I'm being serious, not snarky).
Why even bother with the distinction. Use a unique password for every login. Use something to manage your passwords. If someone is unwilling to generate a password for an unimportant site, they're probably also too lazy to properly generate unique passwords for sites that matter.
I estimate that the average web user understands about 66% of those words. And that's if we give them 'password'.
What if you're integrating with something like a Windows VPN w/RADIUS, which needs the plaintext password?
Bcrypt, while trivial for many applications, is not the answer to everything.
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 their rent too.
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.
Any bets on asdfghjkl;' ??
i think i'll do this tonight
1. Don't reuse passwords. 2. Don't subscribe to porn sites if you have something to lose from someone finding out.
It was actually the passwords to YP Chat, not Youporn itself. The Yourporn guys are pretty reasonable engineers and sysadmins, from what I've seen, and manage user passwords correctly.
Personally, I think in 2012, if you're not using a password manager to generate and manage unique, strong passwords per site, especially for "sketchy" stuff like porn sites, you're already doomed.
Also, Presidents Day and other minor useless holidays are great times for annual rituals like tracking down and changing any legacy shared passwords you may have. Don't wait for a breach!
Yet, friends and HN hackers alike have scoffed at my attitude which is roughly the same as yours. If you're blindly trusting sites with a non-unique password, it's only a matter of time.
(edit) To get ahead of the repeat replies, LastPass syncs across browser extensions, encrypt/decrypts locally, can be accessed from any browser even without an extension and has mobile apps. I've been using it for probably two years now and I've never not been able to access an account even when using all varieties of guest computers, iPads, etc.
I do, however, use a simple templated password. By including a few unique characters (following an easy to remember formula from the sites domain name) in an already strong base password, I can use dozens of unique passwords without any special environment.
If you carry a smartphone, there are several password safes available for these as well.
Clipperz (web-based) and KeePassDroid work for me.
On my primary systems, a simple text-based database GPG encrypted.
Your password template may or may not be good practice. From random cracking, probably safe. If someone takes a particular interest in you and has prior knowledge of your scheme and several revealed examples, other passwords may become discoverable.
For the ones that store information in a local file, that could work. But then a lot of the mobility is lost, even if you use something like Dropbox (you are not going to sync behind a corporate firewall, for instance). At least my brain is attached to my head and is very portable, I just have to remember the damn things.
That said, do you have recommendations?
The one thing I'm waiting for is iCloud integration. If they don't provide iCloud integration, I'd consider other options (including trying to roll-your-own, maybe using their extensions and spoofing the IPC)
Edit: Here's a link (no ads or other junk). http://16s.us/sha1_pass/
I'm not sure how best to make it part of the site sign up process on the server side. The other hassle is you now really want to also link mobile platforms, so unless you're all apple, it's kind of tricky. You could possibly do a web-based password manager instead of something local (there are a few options), or if you're all-apple, 1Password (which doesn't even work perfectly on iOS).
The other way is to just move everyone to Facebook Connect or other third-party identity services, but there are a bunch of problems with that. If there were a single-signon provider which were only single signon, vs. profiles and all the other stuff, it would be more acceptable, but even then, just linkability of all your accounts is a security and privacy compromise, as well as being a single point of attack and failure.
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.
We've been focusing on the rewrite of the main site and are now cleaning up all the secondary dependencies.
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.
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.
I'm wondering what sort of time frame you'd be looking at for a single round password, i.e; md5(salt.cleartext)
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
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.There must be some level of affiliation then, right?
Do you think that it was reasonable behavior to engage in without telling your users?
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.
So you guys cut a deal with another entity to let em "rent" the subdomain chat.youporn? Just intrigued by how this works.
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.
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.
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).
Using chat.youporn.com is not that different than using ypchat.com, personally I would have preferred the latter for obvious reasons.
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.