A Primer on Retail Transaction Security

by Dr. Ralph F. Wilson
Web Commerce Today, Issue 3, October 15, 1997 Unless your customers feel secure about giving you their credit card you won't get very many orders. So to keep evil hackers from stealing credit card numbers, and to provide shoppers with a sense of security, a very fine Web security system has been developed. A secure purchase on your Web site requires three elements: (1) the shopper's secure Web browser, (2) an SSL secure Web server, and (3) a digital certificate. Let's look at each of the pieces, and then we'll put them together. Let me also introduce you Cinderella, a customer in your Web store. We'll use Cindy Shopper to illustrate a purchase of glass slippers. Okay, fasten your seat belts because we're going to get a little technical on you.

Web Browser

Unless your Cindy Shopper has a very old Web browser (like Microsoft Internet Explorer 1.0 or the early version of America Online's browser), then it is equipped for secure transactions. In October 1997, only a very small fraction of Internet users still have old browsers, so let's assume that for all intents and purposes Cindy is using a security-equipped Web browser. Now let's look at requirements on the website side of the transaction and define some terms.

SSL Secure Server

Your Web hosting service needs to have installed an SSL (Secure Sockets Layer) secure server. This can cost them several hundred dollars, so some smaller ISPs don't have them yet. Make sure you ask.

The secure server paired with Cindy's secure Web browser allow browser and server to have a private conversation no one can listen in on. A secure Web address (URL) begins with https:// rather than the usual http://. When Cindy Shopper gets ready to finalize an order and give her credit card number, the Web browser will request a secure Web page such as https://www.mystore.com/creditcard.html. When the server sees the https:// it knows to begin the steps to establish a secure socket, and sends a Digital Certificate.

Digital Certificate

A digital certificate tells Cindy Shopper's Web browser that the store is what it claims to be, that https://mystore.com is actually a legitimate business and not some counterfeit.

To obtain a Digital Certificate the merchant typically sends a copy of a business license, letterhead stationery, and other identifying documentation to the Certificate Authority, an agency which specializes in making positive identification of the merchant. When the Certificate Authority is satisfied the merchant is legitimate (and when you send a several hundred dollar fee), it will send a coded digital certificate to your Web hosting service. When installed on the merchant's website, the digital certificate allows the shopper's Web browser to verify that the certificate matches the URL of the website.

Netscape and Internet Explorer Web browsers have built in codes which verify digital certificates prepared by legitimate Certificate Authorities, such as VeriSign, Inc. of Mountain View, California, USA, and Thawte (prounced like "thought") of South Africa. And since VeriSign, by means of your Digital Certificate, has authenticated My Store of Dayton, Ohio at www.mystore.com, Cindy Shopper's Web browser now feels okay about engaging in a more private conversation -- one which gives credit card numbers, for example.

The merchant's Digital Certificate also contains an encryption code known as a "public key." With that "public key" Cindy's Web browser can encode a message which only the your SSL secure server, with the matching "private key," can decode.

Imagine, for example, that Cindy's Web browser requests the URL https://www.bogus-store.com but the merchant's digital certificate is for https://www.mystore.com. Cindy's Web browser will send a warning: "Digital certificate does not match URL." If everything matches, however, her Web browser will display a whole blue key (Netscape) or padlock (Internet Explorer) in the corner of the screen to let Cindy Shopper know she has a secure connection with the merchant's website.

Now let's see how this system works.

Customer to Website

Cindy Shopper wants to purchase a pair of glass slippers from your shoe department at My Store of Dayton, Ohio. She enters your home page at http://www.mystore.com and begins to shop. What color glass do I want? Red-tinted glass is elegant, but .... She finally settles on clear crystal slippers, size 6, and clicks on the "Order" button. Your computer wasn't in secure mode until now because secure mode is much slower than regular mode. But once she has verified her slipper order, her Web browser now requests a secure page: https://www.mystore.com/creditcard.html and the "dance" begins. Let's watch the steps in this intricate dance.

1. Browser: Cindy Shopper's Web browser requests an https:// page that signals the SSL secure server to identify itself.
2. Secure Server: The secure server sends My Store's Digital Certificate to Cindy's browser.
3. Browser: Cindy's Web browser now checks to make sure of one of the Certificate Authorities' codes embedded in the Web browser will verify that the Digital Certificate is authentic. Then it checks to make sure that the requested webpage is from the same domain name as the Digital Certificate says it should be.

   Her Web browser isn't through, yet, however. It selects a random number which will be used as the basis of the encryption of this shopping session, encrypts it using the public encryption key from the merchant's Digital Certificate, and sends it to your SSL secure server, so now both the browser and the server have the same number to use to encrypt the rest of their conversation. This unique number (called a "Session Key") is huge, at least 40-bits in size (which has 2⁴⁰ different possible combinations). Since each session will be encrypted using a different 40-bit number, it becomes silly for a hacker to invest the time to break the code for a mere credit card number, and hackers don't even try (except, perhaps, to prove to themselves that they could break it given 13 days and a super computer).

4. Secure Server: The secure server now sends back a message saying it got the Session Key, and that all is ready to help spend Cindy's money.
5. Browser: Cindy's Web browser smiles inwardly and displays a whole blue key (Netscape) or a padlock (Internet Explorer) on the screen. At this point, Cindy herself smiles and thinks, "Isn't shopping on the Internet wonderful."

   Cindy now types in her shipping and credit card information and presses the submit button. Her credit card information, encrypted with this Session Key, is sent over the Internet to the SSL server

6. Secure Server: The server, basking in the warmth created by income into your store, now decrypts the credit card information, records it, and sends back confirmation that it has been received.

Of course, we've simplified this dance so you can see the steps, but essentially, that's how it works.

Web Server to Merchant

Cindy's happy, her browser is happy, your SSL server is happy, and you just got an order. But that's only half the story. Most smaller merchants don't have their Web server in-house, they outsource it to a Web hosting service which could be across town or across the country. You still need to receive that order securely.

To tell the truth, many merchants don't give it a second thought. Sadly, many orders are transmitted from the Web server to the merchant's desktop computer without any security at all, often as a naked e-mail message. To have integrity, however, merchants need to honor the trust given to them and protect their customers' credit card numbers with security at the back office part of the transaction, as well. There are three basic ways to do this. Discuss with your website developer how your shopping cart program or order form should be designed to facilitate one of these methods.

1. Secure Web Browser
First, you could display the order with your secure Web browser, print it out, and key it manually into your accounting or fulfillment system. Since you, the merchant, already have a secure Web site and a secure Web browser, you can have the your order-taking program save the order as a single file which can be displayed from an SSL-secure Web browser in a password-protected directory, then print it our on your printer for processing. Make sure that you delete the order files you've processed so a hacker won't be tempted by credit card numbers sitting on your Web server. This method works best when you have only a few orders per day.

A variation on this is to download the order file with your secure Web browser and import it directly into your accounting or fulfillment system. Instead of displaying and printing out the file, you download it to your desktop computer for processing. The secure server and your Web browser will encrypt the file transfer, so the orders get to you safely and securely. With careful planning, you can configure the data so you can import it directly into your desktop program, such as Mail Order Manager, QuickBooks, or Peachtree, as well as a desktop credit card authorization program such as ICVERIFY, PCAuthorize, or MacAuthorize.

2. Encrypted E-Mail
A second alternative is to encrypt the order or order file using an encryption program such as PGP (http://www.pgp.com), and then have it automatically e-mailed to you. You decrypt it on your desktop computer. This is somewhat more involved than using a Web browser, since you'll need to install a copy of PGP both on the server and on your desktop. Then you'll need to send your public key to the server, and program the order system to automatically encrypt the file and e-mail it to you. But once you have it working, this system can work very well indeed, since the order automatically appears in your e-mail box soon after it is made; no daily or hourly trips to the Web to collect orders.

3. SET protocol
Eventually, you'll be able to download orders without special security and transmit the still-encrypted credit card number directly to your credit card processor using the SET (Secure Electronic Transaction) protocol. When the SET standards are fully implemented -- and this may well take a couple of years -- there'll be much less need for a secure server. Cindy Shopper will get a digital "wallet" from her bank which contains her encrypted credit card number. The merchant never sees her number; it is only decoded when it reaches the credit card processor, which verifies that it is a valid card and that funds are available, and sends back a message that the charge is authorized. Unfortunately SET isn't really here yet. "Maybe not today, maybe not tomorrow, but soon, and for the rest of your life."

---

For more information:
"SSL Process" in "Implementing Web Site Client Authentication Using Digital IDs and the Netscape Enterprise Server 2.0," VeriSign, Inc. http://www.verisign.com/repository/clientauth/ent_ig.htm#sslprocess

Electronic Commerce Research Room: Transaction Security links

---

You may read other articles from this issue