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.
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.
Secure transactions
