C’mon fellow mouseketeers… we, like dear Annette and Cubby of years gone by, are no longer virgins (well, web virgins anyway)! Grab that Chastity belt! Katie, bar the door! Lock up your sons and daughters. Raise the drawbridge! Fill the moat! Stock it w/ pirhana if necessary! Its time we talk about data protection! (eeek!). Where does that data go? Where is it stored? How does it get there? Who’s doing what with it?
Data Protection? Yup! It’s one of the major stumbling blocks to e-commerce. If, as a visitor, you don’t feel that your information is safe and/or secure, then you won’t use the web (and provide your credit card) to buy “stuff”… our “stuff” (or our clients’ “stuff”)! Many of us think that (as illustrated by the young lady to the left) if the server is secure… if it has a good firewall, then the data stored there is safe. And while no system is 100% “secure”, this is generally a valid thought process. However, many companies doing e-commerce are NOT doing it on their own servers but are hosting their sites on third-party servers (like IFI). This is especially true of small to medium sized companies on the net. While many hosts (like IFI) do maintain a high level of server security for their clients, much of the e-commerce data is NOT actually stored on the host server! It arrives at the website from your browser, is manipulated in some fashion by the clients’ application and then is RE-transmitted to the client in a form more compatible to their process.
Merely having a secure server… a good “chastity belt” isn’t enough! You want… you need to feel that the road to the server is safe from thieves and prying eyes/hands. And, now that you know that the data… your data may actually be getting sent or transmitted somewhere else, you want to know that your data continues to be safe. Now nevermind that you WILL fax that same information to someone (that you may never have talked personally to) across unsecured telephone lines OR hand your credit card to a waitperson in a restaurant whom you’ve never met before tonight. Nonetheless, what steps can be taken to ensure the security of your data along its entire journey?
SSL. Refers to Secure Socket Layer (or sometimes called Secure Server Layer) is what “locks your browsers’ padlock” and secures your data getting transmitted to a SSL-enabled server (noted by the use of ‘https://’ vs ‘http://’). Think of it as a secure tunnel carrying data from your browser to a company website. Unfortunately as we’ve mentioned, the company (to whom you’re sending the info) often is merely renting space on someone else’s web server. Human nature and corporate budgets being what they are, this usually means the least expensive place they can find (see also related story on “True Web Cost”). Less costs often means less something else… like security measures.
Ok, let’s assume that you got the data to a server safely… now what? Well, if the client has paid to have a database developed, the data *might* stay right there on the host server. There *might* even be restrictions as to who can get to that data (this is where that chastity belt or firewall would come into play). But most likely, the data is no longer in an encrypted form. Decrypting the data on the fly requires additional development cost and requires additional effort on the clients’ part. So, most of the time the data you transmitted doesn’t stop there. As a convenience (to the client), is sent via email to the appropriate company person (usually in an unprotected form). SSL protection does NOT extend to standard email. And many clients use a variety of dial-up/email services OTHER THAN those that are hosting their site.
PGP. PGP takes over where SSL leaves off by encrypting the actual (OUTGOING) email. This is done BEFORE it is sent. Think of it as specially ‘coding’ your data or message. Only the client has the ‘magic decoder ring’, so no matter how long it resides in their email it is protected from viewing by anyone w/o the decryption key.
Do we need both? It kinda depends on who’s getting the data and what they need to do to/with it. SSL makes the site visitor feel all “warm and fuzzy” that their data is safe. And it is… while its being transmitted. While technically it is possible to intercept the data enroute, it takes more effort to do this than to wait for it to stop and then grab it (either while stored unencrypted on the server or in someones’ email). SSL connection, unless required of both visitor and client, does little to protect the data while on the server or AFTER transmission, but does leave it in a readable form.
PGP, on the other hand scrambles (encrypts) the data before its stored on the server or sent via email. It is not readable until it is descrambled (decrypted), so it cannot be usefully databased on the webserver. But it can be stored there or sit in the clients’ emailbox as long as necessary until they process your order.
In some cases, the client may opt to automagically process your order through a third party merchant account (like CardServices International or AuthorizeNet). In this case, often the SSL connection is used between the site webserver and the merchant web site that processes credit cards. PGP is not needed in this case.
