EOS 0.52 Alpha SSL Management.

[SupremeC]

I have made reasons for it...

1. Its not up to a hosting proider or a developer to make the decision on my behalf.

2. I said this before, and its not hard to understand, that not ALL end users have the need for SSL. Suggesting that they should be forced to secure their site to protect name, address, etc. is ridiculous. If they are using 2Checkout, then 2Checkout is the payment processor. In fact, and you must be aware of this David, 2Checkout specifically states  that they are selling your products - not you or your website. A customer will see "2Checkout" on their CC bill, not yourwebsite.com. Furthermore, if you are running a free eBook site, what is the purpose of SSL? How about if your site allows checking out without creating an account And you are using 2Checkout?

A better alternative would be to specifically ask during installation - "Will you be processing credit cards on your site?" If they answer yes then SSL should be set by default. If they select No, then a statement should be shown that it is suggested that they purchase and use an SSL certificate.

I have to ask, who is Eos to force anything on me? I thought it was dirty to add advertisements into CRE and to be honest with you, this is just as dirty. It leaves me wondering what the actual intention is... to open up a opportunity to sell end users products and services that they might not otherwise need?

I'm open to listening to reason.   But I have not heard any reason from you that would justify not making SSL a requirement for ecommerce operations.   

[inetbiz]

Again, I like debate. SupremeC, can you agree with me, that we as hosting providers and software developers should push cart owners to create self signed certificates at minimum to operate in the store admin panel and at least purchase a quick authorization certificate with no insurance in the below $20 category to start up on a shoe-string budget?

While the cart install will prompt for a SSL URL it should NOT be circumvented with http protocol. We can teach and blog quite a bit how to generate a self signed certificate in cpanel and plesk. Anyone who can fill out a form about where they live can create a self-signed certificate.

Perhaps you would assist creating a moodle course section on creating a self signed cert and using it to secure store administration with credit going back to your company as a hosting provider supporting open source since 2003?

I tried to post a positive comment at http://www.supremecenterhosting.com/supremeblog/cre-loaded-just-got-worse/#respond because I too was embarrassed and insulted while supporting you and telling Sal it was wrong to mock your avatar. I could not because the image verification was a broken image.

[David M. Graham]

Due diligence can mean a lot of things and does not specifically mean SSL.

When it comes to securing a website, a good argument can be made for failure in due diligence whenever a simple measure like an SSL cert is not in place. 

No... not interested. I actually have enough info to come to a conclusion and to blog about it too. Eos is open source but the community is not - eerily similar to osCommerce. I think its obvious that you and David think I am stupid and that the prospective end user is as well - if we were not stupid we could see your doing everyone a big favor by making all the decisions for us. Are you going to code all the projects my hosting customers need done [for free], handle support [for free], hold my hand and pay my taxes too?

I don't know.  Do you do this for your "Supreme Cart"  users?   If we went to your forums and asked you to remove the Admin Access with Levels, because we thought it was over kill to be able to control access to that extent in the average online shop would YOU do it on the basis of one person requesting the change? 

Or are there any supreme cart forums?   Google doesn't find any in the first 4 pages on a search for Supreme Cart.  So, just who is more open here?

[David M. Graham]

I still disagree 100%. There is no consensus on the use of SSL when accepting "private" information [name, address, phone number].

You keep harping on credit cards though...

Actually, I am concerned about ALL private information.   While Denver is into collecting the pertinent rules, laws, regulations, etc - I just believe it is WRONG to fail to secure private data passing across the web when security is so cheap.

Ay, there's the rub...

Plenty do and not all would need a security system. If your brick -n- mortar store sold old rusty cans, would you have one?

Most competent managers will tell you it is not just what you sell that generates a need for security, but what you sell it for.....

So, EOS is 'open' as far as source goes but everything else is closed?

I'm open to listening to reason.   But I have not heard any reason from you that would justify not making SSL a requirement for ecommerce operations.   

[inetbiz]

I cited http://www.rsa.com/press_release.aspx?id=5991 written in August of '04 by RSA Security Inc. concerning recent ruling against a leading wholesale club chain obliges industry to understand and adopt a complex range of information security best practices...

RSA Security’s team has cross-referenced regulations from around the world – such as Sarbanes-Oxley, Basel II and the European Union’s Data Protection Directive – and more than 60 best practices derived from the key identity and access management requirements from the associated control frameworks and standards: COBIT, NIST 800-53, ISO 17799, and FFIEC. These were then brought up to date with insight from the SANS Institute, analysts, and in-house RSA Security experience gained from working with more than 18,000 customers worldwide. The best practices are a powerful tool to provide information security controls in the areas of risk management, authentication, access control, data protection and logging and reporting.

I encourage you to read the article.

[zip1]

At the moment there is no code in the cart requiring a SSL, As a matter of fact I have undone a lot of
coding for the admin where it was required to be run under a SSL. Yes it is a dirty little secret for CRe Loaded
that some parts of the admin do no function well unless SSL information is entered into the configure.php for
the admin, but you don't have to have a ssl for EOS.

  As far as what Denver and David is talking about is for the install code. If done, and it has not yet been done.
It would be done so that you could over ride it but one simple edit in the install code. Just like the require I
imposed for php 5.2X or newer for the moment. The Demo site had 5.1.X PHP installed on it but one simple change to
the install allows for EOS to be installed on a server with PHP 5.1.X. Since the install API has note even been
started it is not yet offcially documented, but it will be.

  There are some cases where a SSL is not needed like when a cart is used as just a catalog and
purchases using the checkout is not used. Also if you use the cash, credit, bank transfer, Money order or check
payment modules there is no need to a SSL. Although I would advise it of you are online. We must remember that
EOS is being designed so it can be easily converted into a phone order system or a POS system.


  Also there is no specific law I have been shown that says you absolutely have to have a SSL for Ecommerce.
The Major Credit Card issuing companies have said in writing that you should have your site PCI Compliant.
But there are other companies who do monitory transaction that do have not place the PCI requirements,
the main example is Pay Pal IPN.

  Although the major credit card companies suggest PCI requirements, they will not do anything until there is a
compromise or if the site owner request some sort of verification service.

  So, there is no current requirement for a SSL, if there is it will be documented in the API how to undo that.
To undo it, if implemented, will be very simple to turn off the SSL requirement in the install.

  As far as being decide without community involvement. I have to say there was no community when this was first
discusses. But now that there is a growing community input is not being ignored.

[SupremeC]

You forgot the mandates from the Federal Trade Commission... See my citation below concerning sensitive customer information.

We do not set federal trade commissions rules on sensitive information. They do, not us.

What Federal law? Do you have the statute? I Searched the FTC website and can't find anything there, unless you are referring to their Guide "Protecting Personal Information: A Guide for Business."

Creating an account on a public network computer and giving out your telephone number, street address, NAME, zip code, order history, credit card number excluding either the MID (middle six) or last four or even a paypal transaction ID is sensitive information and the FTC requires you to do due diligence to protect this information. An unencrypted HTTP link is akin to party lines of the early telecom years where 3 or so neighbors would share a telephone line. Easily eavesdropped on and easily able to make notes of bits and pieces of information over time to steal identities and credit card data.

Due diligence can mean a lot of things and does not specifically mean SSL.

You can submit a feature request at http://smeagol.strikehawk.com/mantis/set_project.php?project_id=14 but security will always take precedence over convenience. But, I am grateful for your debate. I understand that you would not reply if you did not care. 

No... not interested. I actually have enough info to come to a conclusion and to blog about it too. Eos is open source but the community is not - eerily similar to osCommerce. I think its obvious that you and David think I am stupid and that the prospective end user is as well - if we were not stupid we could see your doing everyone a big favor by making all the decisions for us. Are you going to code all the projects my hosting customers need done [for free], handle support [for free], hold my hand and pay my taxes too?

[inetbiz]

I still disagree 100%. There is no consensus on the use of SSL when accepting "private" information [name, address, phone number]

Disagreement is healthy. Open Source is a consensus and no one else had rang in on it except, you. Do you have a citation or an authoritative post to share where 100% majority has this consensus?

You keep harping on credit cards though...

Sensitive data can mean a lot of different things to a lot of different people - you will never find 100% consensus on that either. I can not find anything the specifies what other data, besides cc#, pin data, ccv etc, the payment card brands expect you to protect. However, I did find the following:

"For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers."

All self explanatory there... "any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services." If your online store Only uses PayPal, then you would not have to comply but PayPal would if they want to continue processing payment cards.

You forgot the mandates from the Federal Trade Commission... See my citation below concerning sensitive customer information.

Essentially, the "developers" of EOS are creating and forcing their own standard for ecommerce applications - much like Harald and others at osCommerce, your free to do what you like.

We do not set federal trade commissions rules on sensitive information. They do, not us. It would be wonderful to hear from some Europeans on EU law.

Ay, there's the rub...

No rub, there. I did not provide a link nor did I feel it appropriate for a healthy debate. I also told you others sell them, as well.

Plenty do and not all would need a security system. If your brick -n- mortar store sold old rusty cans, would you have one?

rusty old cans? I'd go broke!    The cart will comply with federal and international law. A self-signed certificate for the administration panel cost a store owner zero amount of money to create.

Creating an account on a public network computer and giving out your telephone number, street address, NAME, zip code, order history, credit card number excluding either the MID (middle six) or last four or even a paypal transaction ID is sensitive information and the FTC requires you to do due diligence to protect this information. An unencrypted HTTP link is akin to party lines of the early telecom years where 3 or so neighbors would share a telephone line. Easily eavesdropped on and easily able to make notes of bits and pieces of information over time to steal identities and credit card data.

So, EOS is 'open' as far as source goes but everything else is closed?

You can submit a feature request at http://smeagol.strikehawk.com/mantis/set_project.php?project_id=14 but security will always take precedence over convenience. But, I am grateful for your debate. I understand that you would not reply if you did not care. 

[SupremeC]

I still disagree 100%. There is no consensus on the use of SSL when accepting "private" information [name, address, phone number].

You keep harping on credit cards though...

Sensitive data can mean a lot of different things to a lot of different people - you will never find 100% consensus on that either. I can not find anything the specifies what other data, besides cc#, pin data, ccv etc, the payment card brands expect you to protect. However, I did find the following:

"For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers."

All self explanatory there... "any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services." If your online store Only uses PayPal, then you would not have to comply but PayPal would if they want to continue processing payment cards.

Essentially, the "developers" of EOS are creating and forcing their own standard for ecommerce applications - much like Harald and others at osCommerce, your free to do what you like.

We sell and so do many others a very inexpensive $14.95 RapidSSL certificate good for one year.

Ay, there's the rub...

What company doesn't install an alarm system if they open up a brick and morter store?

Plenty do and not all would need a security system. If your brick -n- mortar store sold old rusty cans, would you have one?


So, EOS is 'open' as far as source goes but everything else is closed?

[inetbiz]

don't know, maybe I am the only hosting provider here that disagree's... I have been using CRE since 2003 and have never experienced any issues that made an SSL cert necessary. Poor coding is what makes CRE insecure... not the lack of an SSL cert.

Admin login and viewing customer order data has to be an encrypted channel to protect sensitive data. A self-signed certificate is definitely alright, there, because it's only the company who will be using the self-signed certificate.

Requesting identity information is done all day long all over the Internet and has been for many years - not an excuse for forcing SSL, unless you are GeoTrust or GlobalSign and are looking at the dollar signs - its over kill and an unnecessary expense on ANY site that does not accept CC's on their domain - which is obviously what both of you [David and Inet] keep harping on. If you are using PayPal, 2Checkout and a number of other payment gateways/processors, its just not needed. IMHO, you will be limiting the user base of the application - not all start ups want to shell out the $$ for a cert and those that don't accept CC's on their domain don't need to.

Customer sign up in the cart requires an encrypted channel because you gather sensitive information. This was the new standard set fourth by the payment card industry council concerning sensitive information (Name, Address, Telephone). We sell and so do many others a very inexpensive $14.95 RapidSSL certificate good for one year.  What company doesn't install an alarm system if they open up a brick and morter store?

By the way... last I new, P3P was dead.

It's not dead. Major browsers cannot come to a consensus to comply with P3P standards set fourth by W3C. Can you say, oh IE? HEH! So, until major browsers adopt it's set on hold but read my link. The standard was adopted and made permanent. I will be planning a workshop in 09 for P3P compliance.

[SupremeC]

I don't know, maybe I am the only hosting provider here that disagree's... I have been using CRE since 2003 and have never experienced any issues that made an SSL cert necessary. Poor coding is what makes CRE insecure... not the lack of an SSL cert.

Requesting identity information is done all day long all over the Internet and has been for many years - not an excuse for forcing SSL, unless you are GeoTrust or GlobalSign and are looking at the dollar signs - its over kill and an unnecessary expense on ANY site that does not accept CC's on their domain - which is obviously what both of you [David and Inet] keep harping on. If you are using PayPal, 2Checkout and a number of other payment gateways/processors, its just not needed. IMHO, you will be limiting the user base of the application - not all start ups want to shell out the $$ for a cert and those that don't accept CC's on their domain don't need to.

Just my opinion... 

By the way... last I new, P3P was dead.

[Bold blue to stress the CC issue]

[inetbiz]

I still think forcing SSL is a bad idea. Again, an unsuspecting user will not be a happy camper after taking the time to download and install the application only to find out they can't use it without an SSL cert - like I did. SSL is not necessary on many sites using an application such as EOS, CRE or osC unless you plan on accepting CC's directly on your site. Many are using other payment gateway's and payment processors [e.g. PayPal] which already have SSL in place.

If you request identity information such as billing address, name and telephone number, you need a secure encrypted channel to send it. You also need good P3P in place.

As far as security goes, there are other ways to secure a site without the need for an SSL cert. There are not too many cases of someone hijacking usernames and passwords during transmission - there is more to it than that. If that were the case, all sites would be using SSL. Anyone with good knowledge of .htaccess, or those willing to take the time to learn, can secure their sites without the cost of a cert. One of the biggest issues is failure to use the correct permissions on configuration files and not using or improperly using .htaccess - not theft of passwords from the zeros and ones.

Filipek, R. 2005 Card issuers fight online fraud The Free Library (June, 1), http://www.thefreelibrary.com/Card+issuers+fight+online+fraud-a0133390270 (accessed January 14 2009)

The PCI standard requires Internet retailers to complete a 12-step security audit that must be certified annually and checked every three months. Starting on June 30, retailers that do not comply with the standard will face heavy fines and could be barred from processing credit card transactions. Credit card companies hope the stricter rules will lead to fewer stolen credit card numbers over the Internet. See Jheary 2007 PCI Compliance, the 12 Step Program (Nov, 29), http://www.networkworld.com/community/node/22442 (accessed January 14 2009)

The standard replaces separate standards and merchant requirements established by individual credit card companies in the past. It incorporates data security best practices from these companies, provides a common compliance document for Internet retailers, and helps establish the responsibilities of anyone using credit card information when data theft occurs.

[ILLUSTRATION OMITTED]

Among the requirements the standard prescribes to safeguard information are:

* Installing and maintaining a firewall system.

* Encrypting transmission of cardholder data and sensitive information across public networks.

* Maintaining secure systems and applications.

* Limiting access to data by businesses to a need-to-know basis.

* Developing a data retention and disposal policy.

* Using and frequently updating antivirus software
.
* Monitoring all access to network resources and cardholder data.

* Testing security systems and processes regularly.

The point I stress, here, is * Encrypting transmission of cardholder data and sensitive information across public networks. your admin pages HAVE to be encrypted because it stores sensitive information and is required by federal law. See RSA.com 2005 A Corporate Minefield: FTC Demands “Reasonable & Appropriate” Measures to Protect Digital Assets (August 04) http://www.rsa.com/press_release.aspx?id=5991 (accessed January 14, 2009)

I think it would be better to STRESS the use of SSL on an ecommerce site - not forcing its use.

So IMHO it makes sense to develop software that complies with federal and international law. I know we intend to tackle taxation at some point.

[David M. Graham]

Michael,

I think you are right, there is more to security than securing the transmission stream.  However, being a little insecure is like being a little bit pregnant.

I heard the same arguments from Sal throughout the time I worked with him - and throughout that time we observed security penetrations on a semi-annual to quarterly basis.  Since Denver and I established our own service, we've put in place all of the security measures he would not allow us to carry out, including dedicated IP's per site with SSL on every store, immediate replacement of default certs during every server deployment and using only secure file transmission protocols.  It would be great to be able to tell you just how much of an improvement in security we have experienced.  Only problem is, we keep running into that pesky divide by zero error...

In short - we have had no file level penetrations of CRE Loaded based sites since we put these measures in place. 

Now, it may be that other policies in place and a lack of custom work applied to our clients sites by external agencies is responsible for this. But should that ever change, we don't have to waste time figuring out where a penetration originated..

SSL certs are cheap.  There is no longer an excuse not to have one.  As far as SSL not being necessary unless you are accepting payment directly on the site, I disagree.

Penetrating an individuals credit information is an intelligence operation.  Such things are often matters of grabbing bits of data and collating them over time.  Every little bit helps.  So, every bit of access denial helps build a more secure environment for all of us.  Going SSL from the start is just the right thing to do.

David

[SupremeC]

I still think forcing SSL is a bad idea. Again, an unsuspecting user will not be a happy camper after taking the time to download and install the application only to find out they can't use it without an SSL cert - like I did. SSL is not necessary on many sites using an application such as EOS, CRE or osC unless you plan on accepting CC's directly on your site. Many are using other payment gateway's and payment processors [e.g. PayPal] which already have SSL in place.

As far as security goes, there are other ways to secure a site without the need for an SSL cert. There are not too many cases of someone hijacking usernames and passwords during transmission - there is more to it than that. If that were the case, all sites would be using SSL. Anyone with good knowledge of .htaccess, or those willing to take the time to learn, can secure their sites without the cost of a cert. One of the biggest issues is failure to use the correct permissions on configuration files and not using or improperly using .htaccess - not theft of passwords from the zeros and ones.

I think it would be better to STRESS the use of SSL on an ecommerce site - not forcing its use.

[David M. Graham]

I'm thinking that we will build a central testing trust authority to issue certificates that are clearly marked as being test certificates.  Compliance scanning authorities might then be able to issue reminders to move to a normal cert before beginning active operations.

Of course, we will be adding information on this in the documentation - one reason I am working to get that done in the Alpha development stages rather than at the last minute. 

At the very least, I think we should have a cert generating script available at the university, and on each participating hosting site to offer free test site certs.

The University will offer course on how to install on various hosting platforms - and I hope some of our hosting operators will be willing to appear as guest instructors for their platforms.  Good Pr, and efficient technical support.

David