What Web Merchants Should Know about Transaction Security

by Dr. Ralph F. Wilson
Web Marketing Today, Issue 21, September 21, 1996

---

This article contains older information. Go here for newer information on shopping carts and transactions.

Is it really safe to make on-line purchases via credit cards? Yes, it most certainly is. But this whole area is developing rapidly. The current issues are transaction security and ID verification of those involved in the transaction. I'll try to explain these highly technical subjects in as simple a manner as possible.

Secure transactions

Technology to carry out secure transactions is here and has been for some time. This centers mainly on:

• Customer to Web Server security
• Web Server to Merchant's Desktop security

Netscape introduced a powerful encryption program in version 1.0 of their Web browser which enabled users to send encrypted messages to similarly-equipped Web servers which supported SSL (Secure Sockets Layer) technology. Less than a year ago Netscape was alone in providing secure Web browsers and Web servers (a Web server is the software your Internet Service Provider uses to make your Web pages viewable on the Web); today all the major Web browsers support SSL, and most of the popular Web servers have SSL versions. The result? Using a Web browser such as Netscape or MS Internet Explorer, your customer in Seattle can send her credit card information safely to your Web server, the first link in the chain.

The next link -- Web server to merchant's desktop -- has not been so widely adopted. Most small businesses don't have their own Web server; they rent Web space from an Internet Service Provider, and those who want to sell directly on the Internet, rent "secure" Web space (that is, equipped with SSL) so customers can communicate securely with their Web server. Let's say you rent Web space for your on-line store in Utah, but you live in Chicago. Not a problem. But how do orders get from Utah to your desktop in Chicago? Either via FTP or e-mail. It's harder to intercept FTP transfers, but e-mail from Utah to Chicago conceivably could be intercepted by an evil hacker. And many stores don't have a clue about encrypting e-mail orders from the Web server to their desktop computer.

Fortunately, it can be done fairly easily. Philip Zimmerman developed Pretty Good Privacy(tm) -- known as PGP -- in the early 90s, which puts a very powerful cryptography encryption program within reach of the everyday computer user. Freeware PGP ver. 2.6.2 is available for non-commercial use for on Unix, DOS, and Mac, as well as ver 5.0 for Windows 3.1 and Windows 95. Network Associates licenses a commercial version of PGP on all three platforms, and has recently released a Windows version which makes the encryption and decryption process rather simple.

To protect their customers' sensitive credit information, businesses need to encrypt e-mail orders which are transmitted from their Web server to their desktop computer. This requires two copies of PGP, one on the Web server to encrypt the orders (probably a Unix operating system), and the other on their desktop (probably Windows or Mac) to decrypt the orders. Several e-mail vendors support a new S/MIME encryption standard, but the trick is to encrypt on your Unix Web server and decrypt on a Windows or Mac desktop. PGP allows you to work cross platform. Of course, if you have a Web server in-house, there is no need to encrypt the orders, but in-house Web servers come with their own set of problems.

An even more common approach is to have the order-taking program write order files in a password-protected area of the website. Then using a Web browser with the SSL-secure server, the order files can be downloaded to the merchant's desktop computer without any breach of security.

Identification

We've talked about the first problem -- secure transmission of sensitive data using encryption. The second problem is to make sure you know who you're dealing with. Right now, SSL-equipped secure servers use what are called "RSA Digital Certificates" to verify the merchant's identity. At present, these are issued by VeriSign, Inc. upon documentary proof that the business is legitimate. The "certification authority" -- VeriSign in this case -- vouches for the identity of your business. This is for your customer's protection.

The latest trend is that customers will be issued a Digital ID of their own. Companies like VeriSign are issuing personal Digital IDs for $6 and $12 from their Web site. The newest generation of Web browsers allow insertion of your Digital ID, so that when your Web browser places an order on-line, the merchant will have a way to verify that it is really you who placed the order. If the merchant wants to, he can even check your Digital ID with the one on file with VeriSign to make sure they match.

The SET (Secure Electronic Transaction) standards which have been developed by Visa, MasterCard, Netscape, Microsoft, and others, carry this a step further. When these are implemented, a Web browser will be able to transmit an encrypted digital ID which contains the customer's credit card number. This number couldn't be decrypted or even seen by the merchant, but would only decrypted when it reaches the merchant's credit card clearinghouse. This fall, the SET standards will be tested, and hopefully, by sometime next year, they'll be fully incorporated into Web browsers, merchant software, and bank software, so the systems will all work together.

How important is all this?

• If you're a merchant wanting to sell directly over the Internet you need to know about the problems of secure ordering and identifying customers.
• If you're a customer, you need to make sure the on-line stores you buy from have true security, both at the front door (Web browser to Web server) and the back door (Web server to merchant desktop).
• If you want to sell directly over the Internet, make sure your Web page designer understands the ins and outs of security and encryption.

---

Sidebar: Public Key Cryptography

Just how does this cryptography work? Skip this section if you like, since this can be confusing. But I'll try to explain it simply.

Remember the decoder ring you got in a cereal box when you were a kid? If both you and your buddy knew the code, he could encode with his ring and you could decode with your ring. That's fine for you and Jimmy, but when you're dealing with the public at large, you don't want to give away the code or it won't be secret any longer.

In 1977, three professors at MIT -- Ronald Rivest, Adi Shamir, and Len Adleman (the initials of their last names are RSA) - invented what is known as the RSA public key cryptosystem, on which SSL, S/MIME, and PGP encryption systems are based.

This is the way it works. Let's say you want to send an encrypted e-mail message to me. Both of us have a cryptography program (PGP, for example). Each of us runs our program and produces a pair of keys. (Like two halves of a map to a buried treasure, you need both halves to find the pot of gold.)

• Public key -- You give a copy of this to anyone who wants to send you encrypted messages, and they use it to encode the message.
• Private key -- You keep this secret, and use a password (or "pass-phrase") to decode with it.

This is a copy of my public key so you can see what one looks like.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 4.0 Personal Edition
mQBtAjIAENgAAAEDAMUSvE3tyms197gVFTbEo+l12v/9
Q4Ytjy5vu8nVyA4rjbfGmuq2JtrbKHHuVNnYkkhtpb7Y
xD4srC8jFmm7Fonc6OYgFgpUnFLkivVMos+FHBFfO6zD
dzs47es+1iieJQAFEbQoUmFscGggRi4gV2lsc29uIDxy
ZndpbHNvbkB3aWxzb253ZWIuY29tPg==
=KnlT
-----END PGP PUBLIC KEY BLOCK-----

If you have PGP, you can use this to encode a private message that only I can decode. You can't even decode the message once you encode it; only I'll be able to read it. Stay with me now.

Netscape and an SSL secure Web server take care of the first step of transmitting the secure order from your customer in Seattle to your secure Web server in Utah. I won't go into the gory details, but the encryption is strong and seamless.

Once the order has been received by your secure Web server in Utah, a PGP encryption program on that computer encodes the order using a copy of your business's public key (don't bail out now), and it is e-mailed to you in Chicago. You decode the message with the PGP program on your desktop computer using your business's private key and password, and then process the order as usual.

Sound confusing? Take my word for it: once it is installed, you'll hardly notice it, but it makes communication of sensitive data safe from prying eyes.

To learn more, check out these resources:

• VeriSign Digital ID Center explains how digital IDs work.
• Visa's page on Electronic Commerce provides an understandable introduction to the SET standards.
• GTE Cybertrust offers a Public Key FAQ which also explains the basics of digital IDs.
• S/MIME Frequently Asked Questions, RSA Data Security, Inc. S/MIME is an emerging e-mail encryption strandard.
• FAQ 3.0 on Cryptography, RSA Data Security, Inc.