I am designing a site for a client and they asked me a question about some legal issues. If we do not have ssl, are my clients liable if somehow a customers information is stolen during transmission from their computer to the web server? What if someone hacks the database, who is responsible?
Latest News: (loading..)
0
19 replies to this topic
#3
Posted 09 June 2003, 12:17
any thime you sign up with a online CC proccessor, its a requirement.. I couldnt even signup for authorize.net till I had one. So if you manage to get CC proccessing without SSL, then yes your client is responsible for a ssl Cert.. they are cheap enough and worth it.
#4
Posted 08 August 2003, 16:05
Most of the cc Processing companies that I looked at will give you a SSL site as part of their package offering. I use authorize.net and they have their own SSL site that I pass my card info to and then take the credit card info on their secured site thus eliminating my need of having my own SSL. Also many hosting companies offer generic SSL sites using their security certificate and just giving you the secured site.
You are always responsible for customer information. I tell most of my clients not to keep cc info on clients for this specific reason. I also suggest they use PayPal since it's the cheapest way to set up an account to receive credit card and for established PayPal members they can pay you out of their checking accounts. PayPal also works nicely with oscommerce.
You are always responsible for customer information. I tell most of my clients not to keep cc info on clients for this specific reason. I also suggest they use PayPal since it's the cheapest way to set up an account to receive credit card and for established PayPal members they can pay you out of their checking accounts. PayPal also works nicely with oscommerce.
Michael Gilliam
#5
Posted 10 August 2003, 00:10
currrently under federal law your not liable for stolen informations if your hacked, however you would be liable if you just openl distibute to information
however, in california, and soon to be federal law, you will be REQUIRED to have SSL any time you collect ANY personal information......... so might as well get a SLL cert. now and beat the rush
however, in california, and soon to be federal law, you will be REQUIRED to have SSL any time you collect ANY personal information......... so might as well get a SLL cert. now and beat the rush
Michael
#6
Posted 03 September 2003, 18:57
be carefull for international order with autorize.net we took a order for $4350.00 and a month after shipping they fax us saying we nee to pay that amount.... they give you no protection wont be useing them for a long time prob be fightng the legal system.. just be care full!!!!
#8
Posted 27 September 2004, 01:23
You've asked about on-line liability in relation to hacking and personal information. We'll, it'll depend on your legal jurisdictions tort and privacy laws.
In general, if a hacker gets into your clients system the client may still be liable whether or not the hacker is caught. It comes down to the systems security protocols and whether or not they are reasonably sufficient to prevent someone from hacking into your clients database. Your client will need to keep on top of security, it is an ever changing area and if they fall behind in their security they may be liable. The courts may see it as a liable tort of negligence and the client has failed in their duty of care to reasonably protect customers personal information and then any breaches of the local jurisdictions privacy laws come into play in addition to the possible tort action.
Other comments cover the credit card issue so I won't mention that.
Although this commentary is of a legal nature it is only a guideline and do not rely on it as professional legal advice. It is recommended that you seek professional legal advise in your local jurisdiction.
In general, if a hacker gets into your clients system the client may still be liable whether or not the hacker is caught. It comes down to the systems security protocols and whether or not they are reasonably sufficient to prevent someone from hacking into your clients database. Your client will need to keep on top of security, it is an ever changing area and if they fall behind in their security they may be liable. The courts may see it as a liable tort of negligence and the client has failed in their duty of care to reasonably protect customers personal information and then any breaches of the local jurisdictions privacy laws come into play in addition to the possible tort action.
Other comments cover the credit card issue so I won't mention that.
Although this commentary is of a legal nature it is only a guideline and do not rely on it as professional legal advice. It is recommended that you seek professional legal advise in your local jurisdiction.
#9
Posted 27 September 2004, 03:07
ECS Skate, on Sep 3 2003, 06:57 PM, said:
be carefull for international order with autorize.net we took a order for $4350.00 and a month after shipping they fax us saying we nee to pay that amount.... they give you no protection wont be useing them for a long time prob be fightng the legal system.. just be care full!!!!
Yes, International business is a much larger risk for U.S.-based businesses. This is the number one reason we only concern ourselves with domestic state-based sales, Canadian sales with a bit more security at hand and forget the few International orders we MAY get that MAY be legitimate.
Authorize.net will not be a far cry from the rest of the gateways and authorizing firms. Anymore, as has been mentioned on these forums intensely, the firms are siding with cosumers here. It is just much much easier to handle verifications and legal matters state-side.
And on topic here, someone mentioned SSL certificates as being economically priced. Not only that, but their benefits FAR outway their cons (are there any cons?).
Even if you were not selling a thing and had a site solely surviving on advertising revenue (eeks), I would still recommend a certificate for when people sign up for the site. It boosts your professionalism in the eyes of the beholder immensely and shows how concerned you are with your readers' privacy (which is top priority in their eyes).
Best of luck, and glad we SE state-siders have our power back.
Ruhl
#10
Posted 27 September 2004, 12:20
There is a way around this issue and one of my clients uses the "Customer Noot Present" method. All data is collected into a database, we have many different databases hidden on the server to collect seperate parts of the card details, then once they log in they can access this data and put it though their merchant terminal.
The problem is that my client got an agreement with the bank to take payments like this, now from past work I have done this does not normally happen and banks insist that YOU are to blame for lose details. I would always recommend that you speak to your bank before you go any further with an issue like this.
The problem is that my client got an agreement with the bank to take payments like this, now from past work I have done this does not normally happen and banks insist that YOU are to blame for lose details. I would always recommend that you speak to your bank before you go any further with an issue like this.
#11
Posted 28 April 2007, 17:26
XtremeCarAudio, on Aug 9 2003, 08:10 PM, said:
currrently under federal law your not liable for stolen informations if your hacked, however you would be liable if you just openl distibute to information
however, in california, and soon to be federal law, you will be REQUIRED to have SSL any time you collect ANY personal information......... so might as well get a SLL cert. now and beat the rush
however, in california, and soon to be federal law, you will be REQUIRED to have SSL any time you collect ANY personal information......... so might as well get a SLL cert. now and beat the rush
Does anybody know what the laws are for Canada?
I'm developing a site for a client. A friend told me that if this website stores CC numbers and if a hacker stole those numbers, I may be liable to lawsuits of hundreds of thousands of dollars, even if I'm the developer and not the owner of the site. Is this correct? If so, how do we set up my osCommerce site so that the CC is not stored in the DB?
My friend told me to do a "Vulnerability Test", which tests to see how easy it is to steal the CC numbers or hack the site. This test costs $2-3K. Does anybody have experience with this and if it is necessary?
Edited by curt0, 28 April 2007, 17:28.
#12
Posted 31 May 2008, 01:58
basically, anywhere in the world:
if you don't take adequate precautions for the type of data you handle, you're liable.
so if you handle credit card numbers, need a LOT of protection. just addresses/names and stuff an SSL is adviseable. don't need any further encryption though. password protect your admin folders obviously... and make sure nobody can view the configure files (With database passwords in).
if you don't take adequate precautions for the type of data you handle, you're liable.
so if you handle credit card numbers, need a LOT of protection. just addresses/names and stuff an SSL is adviseable. don't need any further encryption though. password protect your admin folders obviously... and make sure nobody can view the configure files (With database passwords in).
osCommerce is GREAT. When it works...
#13
Posted 07 June 2008, 19:17
dakatone, on Sep 26 2004, 11:07 PM, said:
And on topic here, someone mentioned SSL certificates as being economically priced. Not only that, but their benefits FAR outway their cons (are there any cons?).
The only con I can think of is that SSL encryption/transmission/decryption does seem to noticeably slow down a site. I suppose another one might be that it gives a false sense of security to both sides. Keep in mind that it only protects data from snooping during transmission -- it does nothing to protect data stored on the customer's PC (including cookies and cache) or your server.
Is there any place on the osC site listing suggestions for "best practices" on safeguarding customer information? It would be good to have something along the lines of
* If you are handling credit card numbers, you need...
* If you are handling Social Security Numbers, you need...
* If you are handling addresses and phone numbers, you need...
These would be at least the minimum legal standards for various countries, plus minimum industry standards.
#14
Posted 07 June 2008, 19:30
It seems to me there's an easy way around this one, just become a government organization, then you can put millions of peoples data onto any media you choose & pass it around without bothering with any security, it doesnt even matter if you loose it!!
Sam
Remember, What you think I ment may not be what I thought I ment when I said it.
Contributions:
Auto Backup your Database, Easy way
Multi Images with Fancy Pop-ups, Easy way
Products in columns with multi buy etc etc
Disable any Category or Product, Easy way
Secure & Improve your account pages et al.
Remember, What you think I ment may not be what I thought I ment when I said it.
Contributions:
Auto Backup your Database, Easy way
Multi Images with Fancy Pop-ups, Easy way
Products in columns with multi buy etc etc
Disable any Category or Product, Easy way
Secure & Improve your account pages et al.
#15
-
- Community Member
- 2,145 posts
- Real Name:Peter Bernard
- Gender:Male
- Location:Kagawong Ontario, Canada
Posted 08 June 2008, 00:36
spooks, on Jun 7 2008, 03:30 PM, said:
It seems to me there's an easy way around this one, just become a government organization, then you can put millions of peoples data onto any media you choose & pass it around without bothering with any security, it doesnt even matter if you loose it!!
And if the gov't does get sued they just write a new law saying they are not liable or any of their friends.
Contributions;
Canada Post Package Tracking
Support System
FirePay / Surefire / Optimal Payments
Become a Community Sponsor
MS2.2 Help Documentation
Canada Post Package Tracking
Support System
FirePay / Surefire / Optimal Payments
Become a Community Sponsor
MS2.2 Help Documentation
#16
Posted 08 June 2008, 09:57
I get the impressions Spooks is making reference to a recent optical storage disc lost in the UK...
http://news.bbc.co.uk/1/hi/uk_politics/7111660.stm
It's kind of amusing now, but a complete disaster at the time!
MrPhil, I think I know what you want, but this is going to get complicated:
Anything really personal, that's credit card numbers, social security numbers etc... get every form of security you can possibly afford. See below.
As for standard details, like addresses and names and telephone numbers:
Well firstly, in the US you have very little data protection legislation, and as such your not really legally obliged to do anything. Which is absolutely ridiculous if you ask me - think where your details may have ended up! The US population is only covered by serious data legislation until they're 13 years old.
It's still adviseale to have SSL and password protected directories etc. though, as (even without legistlation) you can still be sued if you lose data to thieves. And if you want any overseas customers (particularly from Europe) you'll need to stick to the EU data protection legislation, or allowing them to purchase from you is illegal. The EU legislation is as effective/detailed, and in most cases more so, as any other country, so stick to that and you'll be fine.
EU data legislation insists on: safe and secure transmission and safe and secure storage. You also need to provide a method of deleting or correcting the data for your customers, and can't share their information with anyone else without express permission. Oh, and mustn't hold it for longer than necessary, and you can't ask for anything you don't need to know.
So basically, although you have a lot of freedom in the US when it comes to names and addresses, I'd personally advise:
SSL (128 bit will do, but 256 is better for credit card numbers, though not essential)
Password protected admin directories and any other directories
Make sure configure.php files and any others that may give access to the database are protected from access
Turn off indexing of folders (especially admin) that may hold private code
Encrypt (in your database) any credit card numbers, social security numbers, any other really personal numbers of the sort
Lock the door to the room with the server in
Update osCommerce
Always connect to your admin via SSL
Preferably have a server with a firewall of some sort, and have one on your computer too, plus antivirus, antispyware etc
It's a good idea to change the name of your admin directory to something less obvious too, but not essential.
If you're ever unsure with credit card numbers, draw a diagram of where your data is going, why it's going there, and what's protecting it. If there's anywhere on the diagram that doesn't have a good reason, or isn't be 100% protected, find another way or don't do it. Also add to the diagram any methods by which the data can be accessed when it's there, and again write on how you're stopping that... For names and addresses, you don't have to be as thorough, but make sure transmission is always secure and storage has at least one layer of protection (usually the password protection).
http://news.bbc.co.uk/1/hi/uk_politics/7111660.stm
It's kind of amusing now, but a complete disaster at the time!
MrPhil, I think I know what you want, but this is going to get complicated:
Anything really personal, that's credit card numbers, social security numbers etc... get every form of security you can possibly afford. See below.
As for standard details, like addresses and names and telephone numbers:
Well firstly, in the US you have very little data protection legislation, and as such your not really legally obliged to do anything. Which is absolutely ridiculous if you ask me - think where your details may have ended up! The US population is only covered by serious data legislation until they're 13 years old.
It's still adviseale to have SSL and password protected directories etc. though, as (even without legistlation) you can still be sued if you lose data to thieves. And if you want any overseas customers (particularly from Europe) you'll need to stick to the EU data protection legislation, or allowing them to purchase from you is illegal. The EU legislation is as effective/detailed, and in most cases more so, as any other country, so stick to that and you'll be fine.
EU data legislation insists on: safe and secure transmission and safe and secure storage. You also need to provide a method of deleting or correcting the data for your customers, and can't share their information with anyone else without express permission. Oh, and mustn't hold it for longer than necessary, and you can't ask for anything you don't need to know.
So basically, although you have a lot of freedom in the US when it comes to names and addresses, I'd personally advise:
SSL (128 bit will do, but 256 is better for credit card numbers, though not essential)
Password protected admin directories and any other directories
Make sure configure.php files and any others that may give access to the database are protected from access
Turn off indexing of folders (especially admin) that may hold private code
Encrypt (in your database) any credit card numbers, social security numbers, any other really personal numbers of the sort
Lock the door to the room with the server in
Update osCommerce
Always connect to your admin via SSL
Preferably have a server with a firewall of some sort, and have one on your computer too, plus antivirus, antispyware etc
It's a good idea to change the name of your admin directory to something less obvious too, but not essential.
If you're ever unsure with credit card numbers, draw a diagram of where your data is going, why it's going there, and what's protecting it. If there's anywhere on the diagram that doesn't have a good reason, or isn't be 100% protected, find another way or don't do it. Also add to the diagram any methods by which the data can be accessed when it's there, and again write on how you're stopping that... For names and addresses, you don't have to be as thorough, but make sure transmission is always secure and storage has at least one layer of protection (usually the password protection).
osCommerce is GREAT. When it works...
#17
Posted 08 June 2008, 17:51
Thanks for the checklist, Sebastian. I think I'm OK on most of it already, but there are a few items I should look at more deeply. I would like to avoid putting the whole site under SSL, or even just the store (osC), for performance reasons and bogus scary browser warnings. Is there any support in osC for popping out to SSL-protected pages when getting or displaying shipping information and such? I see in the code lots of flags for page links as SSL or not. Can that be done without getting constant warnings about mixed content and going into non-SSL pages? For the time being, I'll leave the CC stuff to PayPal (which is SSL protected), but if I eventually go to a merchant account and handle CC numbers myself, I'll need to do the same thing on pages which handle CC information.
What do other people do? Do they just throw up their hands and put the entire site under SSL? Or run bare and hope nothing happens? I don't have a site up yet to actually play with it -- does osC already switch in and out of SSL as needed? If so, is the drill to get an SSL certificate for the entire site, and just go in and out of SSL (https:) as needed? I'm new to this side of Web design and would like to know what best practices are. Thanks!
What do other people do? Do they just throw up their hands and put the entire site under SSL? Or run bare and hope nothing happens? I don't have a site up yet to actually play with it -- does osC already switch in and out of SSL as needed? If so, is the drill to get an SSL certificate for the entire site, and just go in and out of SSL (https:) as needed? I'm new to this side of Web design and would like to know what best practices are. Thanks!
#18
Posted 08 June 2008, 18:00
MrPhil, on Jun 8 2008, 06:51 PM, said:
Thanks for the checklist, Sebastian. I think I'm OK on most of it already, but there are a few items I should look at more deeply. I would like to avoid putting the whole site under SSL, or even just the store (osC), for performance reasons and bogus scary browser warnings. Is there any support in osC for popping out to SSL-protected pages when getting or displaying shipping information and such? I see in the code lots of flags for page links as SSL or not. Can that be done without getting constant warnings about mixed content and going into non-SSL pages? For the time being, I'll leave the CC stuff to PayPal (which is SSL protected), but if I eventually go to a merchant account and handle CC numbers myself, I'll need to do the same thing on pages which handle CC information.
What do other people do? Do they just throw up their hands and put the entire site under SSL? Or run bare and hope nothing happens? I don't have a site up yet to actually play with it -- does osC already switch in and out of SSL as needed? If so, is the drill to get an SSL certificate for the entire site, and just go in and out of SSL (https:) as needed? I'm new to this side of Web design and would like to know what best practices are. Thanks!
What do other people do? Do they just throw up their hands and put the entire site under SSL? Or run bare and hope nothing happens? I don't have a site up yet to actually play with it -- does osC already switch in and out of SSL as needed? If so, is the drill to get an SSL certificate for the entire site, and just go in and out of SSL (https:) as needed? I'm new to this side of Web design and would like to know what best practices are. Thanks!
By mixed content I assume your using adsense or something similar?
If so you'll need to enclose the adsense code (or other content that's taken from an external source) in the following if statement:
<?php if ($request_type == NONSSL) {
?>
/****ADSENSE (OR OTHER) CODE****/
<?php } ?>
This will stop the non secure content from displaying.
If you set up your SSL certificate address and cookie paths in configure.php it'll only secure the pages that need it automatically, and leave the rest of the site running at normal speed.
An SSL certificate is for an entire domain, all the time. But it's your choice which pages actually use it, and osCommerce is already set up to do this for you. You just need to tell it where your SSL is.
osCommerce is GREAT. When it works...
#19
Posted 08 June 2008, 18:38
I was just over playing with the demo (while you were responding -- thanks), and it does appear to jump in and out of SSL as needed. So all I have to do is get an SSL certificate to cover my entire site, and I (or osC) can pick and choose what's to be protected? That sounds good. osC apparently has already thought of this.
Just curious: for non-osC pages, can I always use the code from application_top.php to look at the env variable HTTPS and determine if I'm coming in under SSL or not? If it's used in osC, I would guess it's pretty dependable. I'll have to try it some time to make sure that this HTTPS variable isn't osC-specific.
What I was referring to about "mixed content" is when an SSL-accessed page (https:) gets something like an image in an unprotected manner (http:). Most browsers complain about that. I see how your code sample works to exclude http: content from an SSL page. Also, there are often browser warnings about going between SSL and non-SSL pages... I'll have to dive into the code and see how osC avoids these nuisance warnings.
Just curious: for non-osC pages, can I always use the code from application_top.php to look at the env variable HTTPS and determine if I'm coming in under SSL or not? If it's used in osC, I would guess it's pretty dependable. I'll have to try it some time to make sure that this HTTPS variable isn't osC-specific.
What I was referring to about "mixed content" is when an SSL-accessed page (https:) gets something like an image in an unprotected manner (http:). Most browsers complain about that. I see how your code sample works to exclude http: content from an SSL page. Also, there are often browser warnings about going between SSL and non-SSL pages... I'll have to dive into the code and see how osC avoids these nuisance warnings.
#20
Posted 08 June 2008, 23:56
MrPhil, on Jun 8 2008, 07:38 PM, said:
I was just over playing with the demo (while you were responding -- thanks), and it does appear to jump in and out of SSL as needed. So all I have to do is get an SSL certificate to cover my entire site, and I (or osC) can pick and choose what's to be protected? That sounds good. osC apparently has already thought of this.
Just curious: for non-osC pages, can I always use the code from application_top.php to look at the env variable HTTPS and determine if I'm coming in under SSL or not? If it's used in osC, I would guess it's pretty dependable. I'll have to try it some time to make sure that this HTTPS variable isn't osC-specific.
What I was referring to about "mixed content" is when an SSL-accessed page (https:) gets something like an image in an unprotected manner (http:). Most browsers complain about that. I see how your code sample works to exclude http: content from an SSL page. Also, there are often browser warnings about going between SSL and non-SSL pages... I'll have to dive into the code and see how osC avoids these nuisance warnings.
Just curious: for non-osC pages, can I always use the code from application_top.php to look at the env variable HTTPS and determine if I'm coming in under SSL or not? If it's used in osC, I would guess it's pretty dependable. I'll have to try it some time to make sure that this HTTPS variable isn't osC-specific.
What I was referring to about "mixed content" is when an SSL-accessed page (https:) gets something like an image in an unprotected manner (http:). Most browsers complain about that. I see how your code sample works to exclude http: content from an SSL page. Also, there are often browser warnings about going between SSL and non-SSL pages... I'll have to dive into the code and see how osC avoids these nuisance warnings.
Yeah go for it. All I know is it works great for me. I use that code on the http accessed content and it doesn't display at all on SSL. OSC take care of the rest.
osCommerce is GREAT. When it works...
