liability for storing member passwords unencrypted?
 

OK so recently I stumbled on a thread in another forum where a victim of credit card fraud had contacted the website his card was used on and was given the username, password and email used to create the bogus account.

The cardholder then attempted to access the email account using the same password, and it worked. Through the email he was able to discover that the thieves had his SSN and quite a bit of other information and also seemed to have stolen the identity of several other people using the same email.

He wanted to report it to the authorities but was concerned since he had made unauthorized entry to someone's email and didn't want to end up getting charged with hacking or whatever.

This led to a lot of anal retentive self declared ipsecurity experts and armchair lawyers claiming that passwords should NEVER be stored as anything but a hash and should not be visible to anyone, ever, no the site owner, not customer service or anyone, and furthermore that storing them in any other way opens the site owner up to criminal (not civil) liability.

I find this highly doubtful simply because it seems that pretty much the entire industry does not work that way. All the industry standard tools that I use or am aware of including nats, mechbunny, netbilling and others make the password visible to admins and CS reps, are frequently used to review for potential fraud patterns, and with the various postback systems it may not even be possible to completely encrypt them.

Is it true that we are all exposing ourselves to criminal liability? Are you guys storing passwords encrypted? Are the passwords visible to anyone? What's the real story?

i dont understand, why even ccbill is showing to program owners plain user and pass combination of members, this is something what i really never understood ... :2 cents: or at least ccbill have been doing that, epoch the same, but epoch crypted at least pass few years ago ... :2 cents: some things that have to be clear, like surfers privacy and security, just dont work that way ... :helpme

What? You store passwords unencrypted? I thought that it was some Flintstone era thing.

I don't know how they are stored, but I all the systems I use allow me to see the passwords of surfers.

Nats, Netbilling, allow me to see it. I just realize I mis-spoke regarding Mechbunny, I cannot see the password there (5.0.6). The camscript also hides it.

My point is that all the passwords secure is my content. So I don't know what my liability to the user is if someone gets ahold of "his" password and sees MY content. I mean sure that's potentially a loss for me, but what are the user's damages? I am guessing zero?

Users damages? I am not security expert, but based on main media news the urser's damage is that the hacker uses the password to all other services where that user has the same password. I don't know about your country, but in many countries you also have oblication to tell to customers that their passwords were stolen. I don't see that being so good for your business.

well, nothing has been stolen and being an adult website most providers don't deliver my mail. The only way they could be stolen is if someone hacked nats, which hasnt happened to my knowlege, in which case they would get a shit ton of expired passwords and a few live ones, or if they hacked netbilling which would be a huge problem for a lot of people but not my responsibility.

I do see that nats does have the ability to store passwords encrypted only but it appears this would destroy my billing setup, as key elements rely on us using self hosted join forms and not the biller's gateway forms.

So, what is the problem with self hosted forms? Why you can't send encrypted passwords?

For example Paypal setup can be secured between your store and Paypal.. well, it is just basic SSL, but that is encryption too. I don't see how encrypting some password in either end would be any different. You know, either send it SSL encrypted to NATS and they do the actual encryption, or you encrypt the password at your end and send it through SSL (or without SSL).

I guess that's based on a cursory review of the documentation. My main tour/upsell setup relies on one click upgrades (token plus) which I am told (and have tested) only works with hosted join forms.

According to this: Member Usernames & Passwords - Tmmwiki

it seems i would need to use the biller's join page as that is the only place the password can be entered in a way that it would get to the biller and thus propagate to the site they are buying access to. If I do that my members would not be able to do the token plus upgrade that allows them to buy site tokens. Maybe I am wrong.

There's not really much legal liability here - you are storing access to YOUR website and not someone elses, so if you are running a paysite and no one can actually cause any monetary damage to the person with that data then there's nothing you are liable for. The fact they are maybe using the same password for thier email and other sites isn't really your fault nor your problem.

Somethign like NATS would have to store them as plaintext because not all scripts and programming languages that may authenticate off of nats db can work with specific hashing methods.

If your database is breached and you have more than 500 California residents in that database you are required to send notice of the breach to them under the California Data Security Breach Act...

Data Security Breach Reporting | State of California - Department of Justice - Kamala D. Harris Attorney General

Failure to do so means possible fines and being the defendant in a class action lawsuit.

That's how I see it. No personal information is stored on the content site.

Depending on what types of data were stolen. Granted it doesn't take much. I know of about 50 porn companies who never disclosed their data breaches to their members. Then again, I know of 50 more that don't even know they have been breached.


I miss the days of the CCBILL log.

If you are the user -- use a throw away password for every sensitive website
Keep a record of them :upsidedow

It's the cheapest insurance against incompetent or careless website operators. The recent hacks of user data at some well known sites comes to mind. At least you jail the damage into that one domain :2 cents:

The email junk signups might as well be 'password' -- they will hijack your junk mail? I hope that is where that 123456: password: qwerty: frequency is found and people are no longer that naïve ...

You are liable for your customer's loss on your website if your site is breached, and his website assets disappear, and you have made no reasonable effort to prevent this -- like cam credits -- on an ethical basis IMHO.

Security Breach Notification Laws

eu-data-breach-notification-rule-the-key-elements
https://privacyassociation.org/news/...-key-elements/

Here's the information covered by Cali's law... usernames with password & email count.

(g) For purposes of this section, ?personal information? means either of the following:
(1) An individual?s first name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted:
(A) Social security number.
(B) Driver?s license number or California identification card number.
(C) Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual?s financial account.
(D) Medical information.
(E) Health insurance information.
(2) A user name or email address, in combination with a password or security question and answer that would permit access to an online account.
(h) (1) For purposes of this section, ?personal information? does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records.

Sony is going to likely feel some heat for doing not encrypting employee passwords and information.