| Installing Security Certificates? |
|
|
|
Written by Bill Davison
January 31, 2006
I've often wondered why with the apparent keen interest in marketing widgets, no one has ever discussed the ins and outs of installing security certificates on host servers / websites?
I realize most simply contract out their on-line ordering but maybe there are others who prefer to customize their on-line shopping. Is protecting your customer's private / credit card information no longer worthwhile?
Bill Davison
bizwebpage.com
Written by Scott Marino February 1, 2006
If you process credit cards, you must have a secure key and
encrypt all credit card data. This is a legal requirement of
Visa/MasterCard, American Express, Discover and all the rest. There are
actually some very stringent rules regarding it that you can get from
your merchant bank.
Security and privacy, especially online, is such a hot issue in the press. The public is cautious about providing any information online, much less credit card details over an un-secure link. Not providing secure check-out and encrypting stored information is like turning off the alarm, leaving the door unlocked, and hoping no robber will notice.
In
past dealings with Verisign and installing the secure keys, it can be a
real challenge. This is actually a good thing as it keeps anyone from
getting a secure key. You have to prove your authenticity before
getting one. Image if it were easy for all these phishers with their
E-bay, Paypal and other bank scam e-mailers to get a secure key.
Scott Marino, President
webundies.com
Written by Bill Davison February 2, 2006
I
too have been through the process more than once and I have to agree.
Therefore, why not discuss the different types / levels, how do they
function, how to acquire a certificate, the cost and most certainly,
how to get it installed on the host server.
Instead of just subject pro and cons, why not some tangible assistance from all these gurus?
Bill Davison
Written by Rich Dudley February 3, 2006
If you have any sort of managed hosting plan (such as shared
hosting or managed dedicated servers), your hosting company will
probably handle this for you -- ask them if that's part of the plan.
You may specify which certificate authority to use (VeriSign, GeoTrust,
Thawte, etc), or they may already be a reseller of one particular brand.
I'm
not sure about Apache servers, but in IIS, it's very simple to generate
a certificate request and install the certificate. Your main choice is
choosing with certificate authority to use. Some, such as Thawte,
require documentation that you are an actual business, and will perform
a check with your Secretary of State (for the international readers,
each business in each US state needs to register with that Secretary of
State, who maintains records of names, business license numbers, tax
information, etc). It can take several days to obtain an SSL with this
type of background check, and these are usually more expensive. Other
CAs, such as Instant SSL, will run a query against a business database
such as Dun and Bradstreet, and generate a certificate quickly.
Certificates from these CAs are usually much cheaper.
In
my experience, consumers don't really care. Many of them have no idea
what an SSL Certificate does for them, only that they've heard you
shouldn't shop at a site without one. Other than that, few people
care. This is spoken from a brick-and-mortar perspective; we have a
physical storefront, and have have one since 1998, so proof if our
business existence isn't as essential as a pure-play Internet
retailer. You can call or walk into our shop, or maybe one of our vans
will pull up outside your house sometime. That goes a long way in
validating our existence.
Something not
to forget is that an SSL Certificate is only half of the solution. To
date, I have never heard of anyone's credit card information being
intercepted and used. This is a very difficult task, even when
security is lax, and it only yields one number. The database is really
the pot of gold as far as thieves are concerned, and these have been
compromised on several occasions. Once the order is processed, you
still need to account for the storage of the credit card number in your
shopping cart database. Ideally, you don't store the full number at
all, only the last 4 digits and the authorization code. Most good
shopping carts will zero out the number after a few days, keeping only
the authorization code and a string of x's or 0's. Anytime the full
card numer is stored, it should be encrypted using strong encryption
algorithm, such as Triple DES. If this isn't a feature of your cart, I
would suggest demanding it or changing your cart, because you do open
yourself up to some liability by not confirming with set and accepted
practices.
Rich Dudley
bloomery.com
Written by Tom Anson February 6, 2006
This isn't really on-topic, and this is probably not the
right forum for asking this, but this discussion of security issues
reminds me of a question that has been bothering me. To whit:
I
was at a website last night, wanting to buy a book. The site made
claims about encryption and security measure (technical stuff that I'm
only vaguely familiar with the language of -- I have no real idea what
it means), but when I went to the order page (even where the credit
card information was collected) the URL was http://~, not https://~; nor was there any other indicator that the page was secure.
I
closed out of the page without placing my order. Was that the right
thing to do? or can there be encryption and stuff on a page without the
https://~ in the URL?
Tom Anson
Anson Aromatic Essentials
Written by Veronica YuillFebruary 7, 2006
Hi Tom
One
way that can happen is if the site uses frames (remember them? ;-)) You
will see the URL of the frameset page in the address bar, which could
be http:// . However, the page displayed in the main frame could be a
secure page using https://. In this case though, the browser won't
display the padlock (because the URL for the whole page is the insecure
frameset one) even though the payment page itself is secure. There's no
way that you can tell if the payment page is secure short of inspecting
the source code of the frameset. I seem to remember quite a large
supermarket chain in the UK had designed their online shopping site
like this at one time.
This is obviously a very poor
design decision, since most people are conditioned, rightly, to look
for the padlock before entering sensitive information.
There
is another way: you could have a form accessed via http:// which was
processed by a secure server-side script (i.e. the form ACTION points
to a https:// page). This is perfectly secure, as the form data will be
encrypted when it's sent -- but again it's a poor design decision
because the visitor cannot see that it's secure unless he/she is savvy
enough to look at the source code.
Incidentally, the
worst order form I've seen was one that was not only not using SSL, but
submitted credit card data to a formmail script which simply emailed
all of the information to the site owner! They didn't get my order ...
Veronica Yuill
Archetype IT
Written by Will Bontrager February 7, 2006 You did right, Tom. https://... is a secure connection between browser and server. http://... is a non-secure connection. Although the chance of sensitive information being compromised on a non-secure connection is low, e-commerce sites who can not be bothered with providing a secure connection for sensitive data transmission may also be irresponsible when handling your information once they control it.
A secure server connection (https://...) automatically encrypts data flowing between browser and server. That's it. A
secure server *connection* does not make a server secure. Webmasters
(and customers), please don't rely on it. Thinking a server is secure
just because it has a certificate with a name to that effect can foster
lackadaisical security.
"Secure server" is a misnomer
because SSL (secure socket layer) does not make the server secure, just
the connection between server and browser.
What
happens to the data after the information arrives at the server via the
secure connection is as important, if not more so. Just because a web
site proclaims their server is secure doesn't make it so. Talk is easy.
If they lie or deceive about one thing, they will do so about other
things. The sensitive customer information should be
stored in browser / robot-inaccessible places for later retrieval.
Retrieval should be at the earliest opportunity. "Browser /
robot-inaccessible" would be:
An example of the latter would be ".cgi" — which most servers are configured to launch and run instead of delivering as-is. Once
retrieved, all information that is not required for the proper
functioning of the system should be removed from the server. Complete
credit card info should never be left on a server. I
am not a security expert. That would be a full-time job. But I do know
a little bit about it. Hopefully a security expert will weigh in here.
One
more point, for merchants. Don't let your software email you sensitive
information such as credit card numbers, unless that email is properly
encrypted. Email is notoriously public, subject to mis-filtering and
misdirecting and ending up on security-lax computers freely accessible
by administrative personnel.
For some of you funds may
be scarce. Security of sensitive customer information, however, is not
a place to skimp. It doesn't have to cost a lot, very little in fact. cgi-resources.com lists several email software titles that can send encrypted email. We
have secure file viewing software for very little money. Secure servers
can be shared, which is an option until you can afford a certificate of
your own -- provided you actually want your own certificate. Get in
touch with me at the domain in my sig and I'll send you a link to a
hosting company that provides shared secure server use at no extra
charge.
Skimp on the expenses, if you need to, but don't skimp on security.
Mr. Anson, look what you started :)
Will Bontrager
willmaster.com
Written by Rich Dudley February 8, 2006
Tom,
The important encryption happens when
the form is sent back to the server. You can view the source of the
page, and find the FORM tag for the order form (there might be several
depending on what else, such as searches or whatnot on the page). The
ACTION attribute should begin https://~ if the page itself doesn't. If
you see this, your information should be encrypted.
It
was common for a long time to encrypt the entire checkout process -- it
was easier, and the presence of the lock was reassuring. However, the
encryption / decryption requires processor power, and some major sites
are only encrypting the important parts of the transmission in order to
save CPU cycles. A little unsettling, especially after nearly a decade
of training to "look for the lock", but still secure.
If the page itself isn't https://~, and the form's ACTION isn't https://~, then you were right to bail out.
I still have the form sent as HTTPS because the encryption is more apparent.
Rich Dudley
The Bloomery
Written by Tom Aman February 9, 2006 "I closed out of the page without placing my order... can there be encryption and stuff on a page without the https://~ in the URL?" - Tom Anson
It
does not really matter whether the page where you enter your credit
card information is http or https. Up to the point where you actually
click the button to *send* the credit card information, it is not
really necessary to use any encryption. BUT, the URL
used when the credit card information is sent must be https to ensure
the info is encrypted. Of course the problem is, that until you click
that button, you have no way of knowing (unless you actually check out
the page source). An example:
If you use Yahoo mail, you can login via a page using the URL http://mail.yahoo.com.
Note that this is an http URL, not an https URL, yet under the Sign In
button it says "New Submits over SSL" (meaning https). When I do the Sign In, I end up at my mail page, again an http page. There is no indication that https was ever actually used. However, if I look at the HTML source for the Sign In page it uses a form and this includes: action="https://login.yahoo.com/config/login_verify2?" So the actual ID and Password are submitted via a secure connection.
In
Tom Anson's case, my own GUESS is that the info is encrypted if the
site's claims are true and that what was actually experienced was a
poor design decision. The page where the credit card information was
collected should have been an https (i.e. encrypted) page so the user
would have confidence in submitting credit card information with
reasonable assurance that the info would, in fact, be encrypted. Tom,
if you have the time, it might be a neighbourly
thing to contact the site and let them know of the situation.
Tom Aman
Aman Software
Comments (1)
Bad Credit Loan
said:
|
|||
| I think as most business managers or owners would understand, before implementing any measure in a business environment the most important part is to weight up the costs versus the benefits. In the case of having your own in-house credit card processing facility, yes you get the benefit of handling all your customer's details and get slightly more marketing insight but the costs involved with all the security measures and requirements are almost always too high to warrant the self implementation. This is probably why you see the big retailers use in-house processing however smaller merchants which account for the other 80% of the internet must use outsource services. |
Write comment
