Although most purchases made on the Internet today are made with credit cards, increasingly merchants and consumers are turning their attention to other kinds of Internet-based payment systems. In contrast to credit cards, these new systems seem to promise a number of possible advantages:
- Reduced transaction cost
Credit card charges cost between 25 cents and 75 cents per transaction, with a hefty 2 to 3 percent service fee on top of that. New payment systems might have transaction costs in the pennies, making them useful for purchasing things that cost only a quarter.
- Anonymity
With today’s credit card systems, the merchant needs to know the consumer’s name, account number, and frequently the address as well. Some consumers are hesitant to give out this information. Some merchants believe that their sales might increase if consumers were not required to give out this information.
- Broader market
Currently, there are many individuals in the world who use cash because they are not eligible for credit cards. Payment systems that are not based on credit might be usable by more people.
From the consumer’s point of view, all electronic payment systems consist of two phases. The first phase is enrollment : the consumer needs to establish some sort of account with the payment system and possibly download necessary software. The second phase is the actual purchase operation. Some payment systems have a third phase, settlement , in which accounts are settled among the consumer, the merchant, and the payment service.
There are several different types of payment systems.
- Anonymous
Payment systems can be anonymous, in which case it is mathematically impossible for a merchant or a bank to learn the identity of a consumer making a purchase if the consumer chooses to withhold that information. Although many anonymous payment systems have been proposed and tested, to date they have all failed.
- Private
Payment systems can be private. With these systems, the merchant does not know the identity of the consumer, but it is possible for the merchant to learn the identity by conferring with the organization that operates the payment system.
- Identifying
Payment systems can identify the consumer to the merchant in all cases. Conventional credit cards and checks are examples of identifying payment systems.
This section describes a variety of payment systems that are used on the Internet today or that have been attempted.
In 1994, First Virtual Holdings introduced its Virtual PIN, a system for making credit card charges over the Internet. The Virtual PIN was unique among electronic payment systems in that it required no special software for a consumer to make purchases with the system. Instead, payments were authorized by electronic mail.
Typical Virtual PINs were “BUY-VIRTUAL”, “YOUR-VIRTUAL-PIN”, “SMITH-SAUNDERS”, and “SPEND-MY-MONEY”.
No encryption was used in sending information to or from the consumer. Instead, the Virtual PIN attained its security by relying on the difficulty of intercepting email. Additional security was provided by the fact that credit card charges could be reversed up to 60 days after they were committed, allowing fraud to be detected and remedied. First Virtual protected itself by not releasing money to merchants until 91 calendar days after a charge was made. Merchants that were creditworthy could apply to get paid within four business days.
To enroll, the consumer needed to fill out and submit a Virtual PIN enrollment form. First Virtual made the form available on its web site and by email. The form included the person’s name, address, and the Virtual PIN that she wished to use,[214] but it did not include the person’s credit card number.
Once the form was received, First Virtual sent the user an email message containing her application number and a toll-free 800 number for the user to call. (A non-800 number was also provided for First Virtual consumers who did not live within the United States.) The subscribers called the 800 number, dialed their First Virtual application numbers using a touch-tone telephone and then keyed in their credit card numbers. This automated voice response system was designed in such a way that customer credit card numbers were never sent over the Internet; at the time that First Virtual was deployed, this added bit of security held considerable interest for First Virtual’s banking partners.
Several hours after the phone call, First Virtual sent the consumer a second piece of email congratulating her for enrolling and giving the user her final Virtual PIN. This Virtual PIN was the Virtual PIN that the user requested, with another word prepended.
The Virtual PIN purchase cycle consisted of five parts:
The consumer gave the merchant his or her Virtual PIN.
The merchant transmitted the Virtual PIN and the amount of the transaction to First Virtual for authorization.
First Virtual sent the consumer an email message asking if the merchant’s charge was legitimate.
The consumer replied to First Virtual’s message with the words “Yes,” “No,” or “Fraud.”
If the consumer answered “Yes,” the merchant was informed by First Virtual that the charge was accepted. If the consumer answered “No,” the charge was declined. If the consumer answered “Fraud,” First Virtual’s staff investigated.
Virtual PINs were not encrypted when they were sent over the Internet. Thus, an eavesdropper could intercept a Virtual PIN and attempt to use it to commit a fraudulent transaction. However, such an eavesdropper would also have to be able to intercept the confirmation email message that is sent to the Virtual PIN holder. Thus, the Virtual PIN system relied on the difficulty of intercepting electronic mail to achieve its security. In practice, First Virtual saw little fraud; one of the most significant cases involved a student who had stolen another student’s Virtual PIN and was able to intercept his email because they used computers on the same local area network.
First Virtual designed the Virtual PIN to be easy to deploy and to offer relatively good security against systemwide failures. Although it was possible to target an individual consumer for fraud, it would have been very difficult to carry out an attack against thousands of consumers. And any small amount of fraud could be directly detected and dealt with appropriately, for example, by reversing credit card charges.
The Virtual PIN gave the purchaser considerably more anonymity than do conventional credit cards. With credit cards, the merchant knows the consumer’s name: it’s right there on the card. But with the Virtual PIN, the merchant knew only the Virtual PIN—and the consumer could change his Virtual PIN whenever he wished.
Because each transaction had to be manually confirmed, the Virtual PIN also protected consumers from fraud on the part of the merchant. Consumers who used the system said that they did not consider manually confirming every transaction to be burdensome.
First Virtual’s payment system was the first working digital payment system on the Internet. Unfortunately, while First Virtual’s creators thought that the system would be used by all sorts of e-companies, the main reason for interest in First Virtual was for the buying and selling of pornography. Worried about being associated with the smut industry, and failing to realize the size of the market, First Virtual segregated the smut services off its main web site and gradually made it more difficult for the Virtual PIN to be used for that purpose.
Unable to make significant revenue from the Virtual PIN, in the end First Virtual decided to leverage its experience in sending and receiving large amounts of email and became MessageMedia, a company that specializes in sending promotional email over the Internet.
DigiCash was an electronic payment system developed by Dr. David Chaum, the man who is widely regarded as the inventor of digital cash. Also called E-Cash, the system was sold by Dr. Chaum’s company DigiCash BV, which was based in Amsterdam. The system was fielded in the United States by the Bank of Mark Twain in 1996.
DigiCash was based on a system of digital tokens called digital coins . Each coin was created by the consumer and then digitally signed by the DigiCash mint, which was presumably operated by a bank or a government. Users of the system could exchange the coins among themselves or cash them in at the mint, a process similar to a poker player’s cashing in his or her chips at the end of the day.
To enroll with the DigiCash system, a consumer needed to download the DigiCash software and establish an account with an organization that could both mint and receive the DigiCash digital coins. These digital coins were to be backed by some other currency that the bank had on deposit, such as dollars or gold. In theory, though, digital coins could be backed by anything that two parties might find of value—for example, gallons of honey, megawatt hours on the futures market, copies of this book, or even computational time on a network of workstations.
DigiCash accounts consisted of two parts: a deposit account at the financial institution and an electronic wallet that was maintained on the user’s computer. To obtain DigiCash, the user’s software created a number of electronic coins—blocks of data. Parts of these coins were then blinded, or XORed with a random string. The coins were then sent to the mint to be signed. For each dollar of coins that the mint signed, an equal amount was withdrawn from the user’s account. The coins were then returned to the user’s computer, where they were XORed again. In this manner, it was impossible for the issuing institution to trace back spent coins to the particular user who issued them.
To make a purchase with DigiCash, the consumer needed to be running a small program called the DigiCash wallet. The program spoke a protocol that allowed it to exchange coins with a merchant system and with its wallets. Coins could also be sent by email or printed out and sent by other means.
Chaum developed digital cash systems that offered unconditional anonymity as well as systems that offered conditional anonymity: the consumer always knew the identity of the merchant, and the merchant could learn the identity of the consumer if the consumer attempted to double-spend money.[215]
The DigiCash system is routinely showcased as a model system that respects the privacy of the user. The idea is that DigiCash could be used for a series of small transactions, such as buying articles from an online database, and merchants would be unable to combine information gleaned from those small transactions to build comprehensive profiles of their users.
However, an anonymous payment system is not sufficient to assure the anonymity of the consumer. That’s because it may be necessary for the merchant to learn identifying information about a consumer to fulfill the consumer’s purchase. For example, during a DigiCash trial in 1995, one of the things that could be purchased with DigiCash was a T-shirt. However, to deliver the T-shirt, the merchant needed to know the name and address of the person making the purchase.[216]
Perhaps one reason that DigiCash did not catch on is that there was never a real market need for the technology. Chaum’s original motivation for developing DigiCash was to allow electronic database and library companies such as Lexis/Nexis to sell small pieces of information in a piecemeal fashion—DigiCash would protect people’s right to read what they wished in total anonymity. But Lexis/Nexis never wanted a DigiCash-based system. Instead of selling information piecemeal to the public, these companies offer accounts to their customers with different kinds of purchase plans. Some plans have a relatively high cost for occasional use, whereas other plans have a lower cost for higher volumes or for off-hour access. Offering different plans to different kinds of customers allows a database company to maximize its profits while simultaneously using its infrastructure more efficiently. Meanwhile, the users of these services have not demanded the ability to perform their searches and download the results anonymously. Despite the lack of anonymity, users of these services do not seem to worry that their database searches may be scanned by their competitors. At least so far, database vendors seem to realize that customer records must be held in confidence if customers are to be retained.
Despite a tremendous amount of publicity, DigiCash was never able to create a critical mass. DigiCash eventually ran out of money and was forced to declare bankruptcy. The DigiCash algorithms, on the other hand, are well understood and live on. Despite being protected by various patents, there are numerous individuals who continue to experiment with them.
CyberCash’s first digital payment system was designed to let conventional credit cards be used securely over the World Wide Web. By “securely,” CyberCash meant that merchants would never be able to see the credit card numbers of their customers. Instead, the merchant received encrypted credit card numbers and passed them along to their merchant bank. The system was designed to limit the fraud that a merchant could commit, and thus make it easier for companies to become merchants and accept credit cards.
The CyberCoin system was an adaptation of the technology for small-value transactions. Instead of issuing a credit card charge, the CyberCash server can be thought of as a debit card.
Before using CyberCash, the consumer had to download special software from the CyberCash web site, http://www.cybercash.com/. The software was called the CyberCash wallet. This software maintained a database of a user’s credit cards and other payment instruments.
When the wallet software first ran, it created a public key/private key combination. The private key and other information (including credit card numbers and transaction logs) was stored encrypted with a passphrase on the user’s hard disk, with a backup key stored encrypted on a floppy disk.
To use a credit card with the CyberCash system, the credit card had to be enrolled. To create a CyberCoin account, a user had to complete an online enrollment form. The CyberCash implementation allowed money to be transferred into a CyberCoin account from a credit card or from a checking account using the Automated Clearing House (ACH) electronic funds transfer system. Money that was transferred into the CyberCoin account from a checking account could be transferred back out again, but money that was transferred into the account from a credit card could only be spent. (The reason for these restrictions was both to reduce fraud and to deal with the higher cost of using credit cards compared with ACH.) CyberCash allowed the user to close his or her CyberCoin account and receive a check for the remaining funds.
The CyberCash wallet registered itself as a helper application for Netscape Navigator and Microsoft’s Internet Explorer. Purchases could then be initiated by downloading files of a particular MIME file type.
When a purchase was initiated, the CyberCash wallet displayed the amount of the transaction and the name of the merchant. The user then decided which credit card to use and whether to approve or reject the transaction. The software could also be programmed to automatically approve small-value transactions. The first version of the software was programmed to automatically approve transactions less than five dollars, raising the danger that merchants might create web pages that stole small amounts of money from web users using the <IMG SRC=> feature without the user’s knowledge. (This behavior was changed after the product’s launch.)
If the user approved the transaction, an encrypted payment order was sent to the merchant. The merchant could decrypt some of the information in the payment order, but not other information. The merchant’s software would add its own payment information to the order, digitally sign it, and send it to the CyberCash gateway for processing.
The CyberCash gateway received the payment information and decrypted it. The gateway checked for duplicate requests and verified the user’s copy of the invoice against the merchant’s to make sure neither had lied to the other. The gateway then sent the credit card payment information to the acquiring bank. The acquiring bank authorized the transaction and sent the response back to CyberCash, which sent an encrypted response back to the merchant. Finally, the merchant transmitted the CyberCash payment acknowledgment back to the consumer.
CyberCoin purchases were similar to CyberCash purchases, except that money was simply debited from the consumer’s CyberCoin account and credited to the merchant’s account.
The CyberCash payment was designed to protect consumers, merchants, and banks against fraud. It did this by using cryptography to protect payment information while it was in transit.
All payment information was encrypted before it was sent over the Internet. But CyberCash further protected consumers from fraud on the part of the merchant: the merchant never had access to the consumer’s credit card number.
Despite the security and the convenience of using CyberCash, consumers were slow to adopt the system. One reason offered was the size of the CyberCash client software—several megabytes. At the time, it would have taken most consumers the better part of an hour simply to download the software and install it. Because few consumers had the software, few merchants were interested in spending the money to implement the CyberCash protocols on their own systems. Because few merchants were interested, few banks ever geared up for CyberCash.
CyberCash eventually dropped support for the consumer wallet and instead concentrated on processing credit card orders for merchants that were delivered to merchant web sites using standard web forms and SSL. After a successful initial public offering of its stock, CyberCash made a number of strategic purchases and investments and soon ran out of money. The company was forced into bankruptcy and was eventually purchased by VeriSign.
SET is the Secure Electronic Transaction protocol for sending payment card information over the Internet. SET was designed for encrypting specific kinds of payment-related messages. Because it cannot be used to encrypt arbitrary text messages, programs containing SET implementations with strong encryption have been able to receive export permission from the U.S. State Department.
The SET standard was jointly developed by MasterCard, Visa, and various computer companies. Although the SET initiative appears to be dead, detailed information about SET can still be found on the MasterCard web site at http://www.mastercard.com/ and on the Visa web site at http://www.visa.com/. It is worth taking a look at how this initiative was intended to work.
According to the SET documents, some of the goals for SET were to:
Provide for confidential transmission
Authenticate the parties involved
Ensure the integrity of payment instructions for goods and services order data
Authenticate the identity of the cardholder and the merchant to each other
SET uses encryption to provide for the confidentiality of communications and uses digital signatures for authentication. Under SET, merchants are required to have digital certificates issued by their acquiring banks. Consumers may optionally have digital certificates issued by their banks. During the SET trials, MasterCard required consumers to have digital certificates, while Visa did not.
From the consumer’s point of view, using SET is similar to using the CyberCash wallet. The primary difference is that support for SET was to be built into a wide variety of commercial products.
In a typical SET transaction, there is information that is private between the customer and the merchant (such as the items being ordered) and other information that is private between the customer and the bank (such as the customer’s account number). SET allows both kinds of private information to be included in a single, signed transaction through the use of a cryptographic structure called a dual signature .
A single SET purchase request message consists of two fields, one for the merchant and one for the acquiring bank. The merchant’s field is encrypted with the merchant’s public key; likewise, the bank’s field is encrypted with the bank’s public key. The SET standard does not directly provide the merchant with the credit card number of the consumer, but the acquiring bank can, at its discretion, provide the number to the merchant when it sends confirmation.[217]
In addition to these encrypted blocks, the purchase request contains message digests for each of these two fields, and a signature. The signature is obtained by concatenating the two message digests, taking the message digest of the two message digests, and signing the resulting message digest. This is shown in Figure 25-2.
The dual signature allows either the merchant or the bank to read and validate its signature on its half of the purchase request without needing to decrypt the other party’s field.
To understand why SET was not successful, consider the system from the consumer’s point of view. Before a consumer could purchase something with SET, the consumer needed to follow these steps:
The consumer needed to first obtain the digital wallet software. This software was never distributed with web browsers. Instead, it needed to be separately downloaded.
The consumer needed to type his credit card number into the wallet software.
The consumer needed to obtain digital certificates for each credit card.
Finally, the consumer needed to find a web site that was enabled to process SET transactions.
In the end, few customers went to the trouble of downloading the SET wallets. Those who did discovered that there were few merchants on the Internet who supported the protocol. And because SET offered no direct advantage to the consumer—it didn’t really speed up purchasing, and it didn’t offer a discount—there was no real incentive for ISPs and software publishers to prebundle SET with programs such as web browsers or email clients. Despite the huge support by Mastercard, Visa, Microsoft, and others, SET never really got off the ground.
Before you can use the SET system, you must first enter your credit card number into the electronic wallet software. Most implementations will store the credit card number in an encrypted file on your hard disk or in a smart card. The software also creates a public key and a secret key for encrypting your financial information before it is sent over the Internet.
When you want to buy something, your credit card number is encrypted and sent to the merchant. The merchant’s software digitally signs the payment message and forwards it to the processing bank, where the Payment Server decrypts all of the information and runs the credit card charge. Finally, a receipt gets sent back to both the merchant and you, the customer.
Boosters of SET said that banks would be excited by the technology because SET kept credit card numbers out of the hands of the merchants. SET’s supporters figured that would cut down on a lot of fraud, because it is merchants (and their employees), and not teenage hackers, who are responsible for much of the credit card fraud in the world today. But in practice, the added security provided by SET was not sufficient to interest many banks, as they had already created sophisticated systems for detecting merchant fraud. Furthermore, most of the early SET implementations ended up providing credit card numbers to the merchant anyway using the SET merchant channel, because the merchant computers required the consumer’s credit card numbers so that the legacy software could function properly.
PayPal is an electronic payment system that can be used to transfer money between any two people on the Internet, provided that both individuals have an email address and a credit card or bank account. PayPal is commonly used to settle purchases made on Internet auction sites such as eBay. In recent years, PayPal has become one of the Internet’s most popular payment systems.
PayPal advertises that its payment system can be used to send money to “anybody”—all you need to know is that person’s email address. In fact, PayPal can only be used to send money to other PayPal users. If you send money to a person who is not a PayPal user, PayPal will send that person email telling them that they have money waiting; all they need to do is to open a PayPal account. It is this ease of account creation that is largely responsible for PayPal’s success.
Besides being used to settle auction payments, PayPal increasingly is hunting for other business opportunities. In 2001, the company started aggressively marketing to business customers, saying that PayPal is “the cheapest way to accept payments online. E-commerce has never been easier!” PayPal also has a free shopping cart system (although customers can only settle their accounts with PayPal). The company also has a credit card.
Sending money with PayPal is remarkably easy:
Assuming that you have a PayPal account, you simply log into PayPal’s web site with your username and password.
Click the button “Send Money.” (See Figure 25-3.)
Specify the recipient’s email address. (PayPal keeps an address book of people to whom you have recently sent money.)
Specify the amount.
Specify the reason for the payment. (PayPal allows you to specify payment for Service, Goods, or Quasi-Cash.)
Specify a subject line.
Specify a note, if you wish.
Click Continue.
PayPal will display the details of the transaction and allow you to confirm the payment. At this point, you can pick your funding option—you can transfer money from a PayPal account, from a checking account, or from a credit card that you have registered.
Once the money is sent, PayPal sends a confirmation email to both the initiator and the recipient of the transaction, as shown in Example 25-1.
Example 25-1. The message sent from PayPal to the initiator of a transaction
Return-Path: <payment@paypal.com>
Delivered-To: simsong@r2.nitroba.com
Received: from sandbox.sandstorm.net (user-v3qtgdr.biz.mindspring.com [199.174.193.187])
by r2.nitroba.com (Postfix) with ESMTP id 3A2F2E44322
for <simsong@walden.cambridge.ma.us>; Sun, 23 Sep 2001 21:06:10 -0400 (EDT)
Received: from mail.acm.org [199.222.69.4]
by sandbox.sandstorm.net with esmtp (Exim 2.05 #2 (Debian))
id 15lKCH-0005qC-00; Sun, 23 Sep 2001 21:06:09 -0400
Received: from web7.sc5.paypal.com (web7.sc5.paypal.com [216.136.154.243])
by mail.acm.org (8.9.3/8.9.3) with SMTP id VAA24882
for <simsong@acm.org>; Sun, 23 Sep 2001 21:05:08 -0400
Received: (qmail 5175 invoked by uid 99); 24 Sep 2001 01:05:11 -0000
Date: Sun, 23 Sep 2001 18:05:11 -0700
Message-Id: <1001293511.5175@paypal.com>
From: service@paypal.com
To: simsong@acm.org
Subject: Receipt for your Payment
This email confirms that you sent $1.00 to beth@vineyard.net.
------------------------------
Payment Details
------------------------------
Amount: 1.00
Transaction ID: 9NW39779FC564471A
Subject: because I love you
Note: Beth,
You do such a wonderful job with the kids! Here is some more money because I love you so much.
--------Simson
View the details of this transaction online at:
https://www.paypal.com/vst/id=6J173029UP867832W
---------------------------------------------------------------
This payment was sent using your bank account.
By using your bank account to send money, you just:
- Avoided incurring debt on your credit cards.
- Sent money faster than writing and mailing paper checks.
- Received an additional entry in our $10,000 Sweepstakes!
Thanks for using your bank account!
---------------------------------------------------------------
Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address
cannot be answered. For assistance, login to your PayPal
account and choose the "Help" link in the footer of any page.PayPal’s popularity comes from its ease of use, but its strength comes from a remarkably well-thought-out approach to practical financial security.
When a person first signs up to use PayPal, the person will typically provide a credit card. To register the credit card, PayPal requires that the user enter the credit card account number, expiration date, and billing address. This is precisely the same information that is required to process a charge. The operating theory is that if you know enough about a person and her credit card to buy something over the Internet, then you should be able to use that credit card to send people money over the Internet. And besides, credit card charges are reversible, so the whole thing is generally pretty safe—certainly no less safe than credit cards themselves.
When a person registers a bank account with PayPal, the company takes other precautions to make sure that you are an authorized user of the bank account. It would be nice if PayPal could just call up your bank and ask them if their user is authorized to use the account, but how does PayPal know who their user is? There is really no way to be sure. Perhaps more importantly, PayPal really doesn’t care who the user is—they just want to be sure that the person is authorized. To find out if you are authorized to use a bank account, PayPal initiates two ACH credits for less than a dollar to the account. PayPal then asks you to call up your bank, get the value of these two transactions, then log back into the PayPal site and enter the dollar amounts. If a person has access to this transaction-level information, the theory goes, then that person must be the authorized user of the account.
If a PayPal account is broken into—if somebody guesses your username and password—then it is hoped that the confirmatory email that PayPal sends out will alert the PayPal user to change his or her password. If not, then again it is hoped that PayPal will be able to reverse any fraudulent transactions. And what if PayPal can’t reverse the transaction? What if money was transferred from your bank account to another person’s bank account and it was immediately withdrawn? Well, PayPal claims that each of its accounts is automatically insured for up to $100,000 against unauthorized withdrawals by Travelers Insurance.
Gator is not a payment system per se, but it is tempting to think of it as such because it offers many of the same conveniences of the SET or DigiCash payment systems.
Gator is a digital wallet that runs on Microsoft Windows and is tightly integrated with Internet Explorer. Gator constantly monitors every web page that is displayed in Internet Explorer and scans it for forms that it knows how to fill in (see Figure 25-4). If Gator sees a form asking for your name, address, Zip, or other information, the Gator wallet displays a little tab on the side of your window to let you know that it knows how to fill out the form. If you click on the tab, Gator will fill out the form using information that you previously provided. (See Figure 25-5.)
Figure 25-4. Gator Wallet constantly scans the pages displayed in Internet Explorer for forms that it knows how to fill out
Besides your name and address, you can also load one or more credit cards into Gator. If Gator knows your credit card information, you can fill out a “payment” page with the click of a single button. By automatically filling out forms, Gator makes it dramatically easier to spend money online.
To use Gator, it is necessary to go to the Gator web site (http://www.gator.com/), create an account, and download the Gator software. Gator account names are email addresses, which guarantees that they will be mostly unique. Once the software is running on your computer, you type in personal information such as your name, address, and credit card numbers. Gator can also memorize the username and password that you provide for each web site that you visit.
Gator stores information on your computer encrypted with a passphrase. (It is not clear what encryption algorithm is used or if the encryption provides adequate security for the information that is provided to the program.) Because people sometimes forget their passphrases, the software has a button labeled “Forgot your password?” Clicking the button and answering some questions will ultimately result in having your Gator password sent by email to the registered email address.
Of course, Gator’s willingness to send the user’s password to the user’s email system mitigates the value of having the personal information stored in an encrypted form. The whole point of using encryption to store the user’s personal information, presumably, is so that if somebody gets hold of the user’s computer, that person will not have access to highly sensitive information such as the user’s credit card numbers. However, if Gator then goes ahead and emails the user’s password, it’s quite likely that the attacker will be able to use other information on the user’s computer (such as a remembered password in an email program) to pick up the victim’s email and, as a result, get his Gator password. Gator says that you can send the company email and ask that it never reveal your password, but it is not clear how this mechanism is enforced.
One significant shortcoming with form-filling systems such as Gator is that the wallet program must parse the HTML provided by the remote web site and attempt to figure out the semantic meaning of each field. Sometimes, this job is easy: if there are fields named NAME, ADDRESS, CITY, STATE, and ZIP, it is pretty safe bet that the fields refer to a person’s U.S. postal address. Other times, the meaning of the fields can be cryptic: most form-filling programs would be bewildered by those same names translated into Japanese.
At first glance, Microsoft’s Passport looks like a an attempt to eliminate the need to fill out forms with shipping and payment information. Instead of filling out this information at each web site, the information is entered once on the Microsoft Passport server (see http://www.passport.com). But Passport goes beyond a simple form-filling system. Passport allows web sites to use the Passport service as a single sign-on system. Once a user signs into Passport, that user can jump into any passport-enabled web site without having to enter a name or password.
When a user visits a site that is Passport-enabled, if he has already logged into the Passport system, the Passport-enabled web site has access to the user’s name and identifying information. If the user has not logged in, the user can press a “login” button and will be prompted for his username and password. After this information is entered, activity continues as before, except now the user is logged into the Passport system.
Currently, web sites can only use Passport if they are hosted on computers equipped with the Windows operating system and Microsoft’s Internet Information Server. It works better with Internet Explorer than with Netscape Navigator.
Passport’s design has raised several concerns:
- Data theft and appropriation
Suppose that someone is trying to steal your personal information to commit fraud. Without Passport, they would need to find and then penetrate the computers on which your data is stored. Usually, this means that an attacker needs to find the names of the merchants that you work with, then guess your username, and finally guess your password. With Passport, however, they only need to intercept or guess the password you have selected to protect your Passport account, since the location of Passport’s servers are well known and your username is your email address.
- Data protection
All the user data present on the Passport site is potentially vulnerable to attackers. Although Microsoft is committed to protecting the data, there is no guarantee of security. In recent history, there have been several high-profile penetrations and failures of Microsoft sites. Thus, there is a risk that Microsoft’s servers will be penetrated and the personal information they contain will be appropriated. Certainly, Passport’s servers are sure to be a target of attackers.
- Cascading loss of security
If Passport is successful, many users will be encouraged to use it from locations that aren’t secure. For example, a person visiting an Internet cafe might be tempted to type in his Passport username and password to view his customized news at a financial web site. But the computer at the cafe might not be secure—it could be running a program that automatically records every keystroke that is typed. Because of the Passport design, once the username and password for any web site in the Passport system is compromised, that user’s personal information for all web sites is compromised. The result is that Passport users have a greater chance of suffering fraud or privacy loss at multiple web sites when their usernames and passwords are compromised, because the single username and password is used at so many different locations.
- Data aggregation and mining
A great deal can be inferred about customers by observing the data and the nature of sites requesting that data. Even more can be learned by combining data from many users visiting many different web sites. Thus, the database of Passport users and its authentication logs are potentially quite valuable and would seem to present a wonderful opportunity for people skilled in the art of data mining. Although this data mining seems to run counter to Microsoft’s current privacy policy, there is no guarantee that the policy might not change. Nor are there any technical guarantees that the policies against data mining will be strictly observed.
Overall, it remains to be seen whether Passport will be well accepted. Currently, the service is new and has not been widely adopted. A well-publicized security break-in or exposure of personal information might well sink the service, especially as there are familiar and workable alternatives.
In the years to come, the distinction between Internet and non-Internet payment systems is likely to blur or be erased. As PayPal money can be beamed as digital “checks” from one PalmPilot to another, it’s likely the future will see the emergence of more payment systems that work equally well in the online and offline worlds.
Smart cards may well be the basis of any future payment system because they offer the security of systems like SET coupled with the convenience of traditional magnetic-strip-based credit cards. Indeed, smart cards look like credit cards except that they store information on microprocessor chips instead of magnetic strips. Compared to conventional cards, smart cards differ in several important ways:
Smart cards can store considerably more information than magnetic strip cards can. Whereas magnetic strips can hold a few hundred bytes of information, smart card chips can store many kilobytes. Furthermore, the amount of information that can be stored on a smart card is increasing as chip densities increase. Because of this increased storage capacity, a single smart card can be used for many different purposes.
Smart cards can be password-protected. Whereas all of the information stored on a magnetic strip can be read any time the magnetic strip is inserted into a reader, the information on a smart card can be password-protected and selectively revealed.
Smart cards can run RSA encryption engines. A smart card can be used to create an RSA public/private key pair. The card can be designed so that the public key is freely readable, but the private key cannot be revealed. Thus, to decrypt a message, the card must be physically in the possession of the user. This gives high assurance to a user that her secret key has not been copied.
Smart cards have been used for years in European telephones. In the summer of 1996, Visa International introduced a Visa Cash Card at the Atlanta Olympics. Within the coming years, smart cards are likely to be more generally deployed throughout the United States. In 1996, the Smart Card Forum estimated that there would be more than 1 billion smart cards in circulation by the year 2000. That didn’t happen, and the Forum has not made public any future projections. Nevertheless, it seems likely that smart cards will continue to proliferate.
Mondex is not an Internet-based payment system, but it is one of the largest general-purpose digital payment systems currently in use.
Mondex is a closed system based on a small credit-card-sized smart card that theoretically cannot be reverse-engineered. Mondex uses a secret protocol. Therefore, what is said of Mondex depends almost entirely on statements from the (somewhat secretive) company.
Each Mondex card can be programmed to hold a certain amount of cash. The card’s value can be read by placing it in a device known as a Mondex wallet. Money can be transferred between two wallets over an infrared beam. Merchants are also provided with a special merchant wallet. Mondex can also be used to make purchases by telephone using a proprietary telephone. The card may be “refilled” using a specially equipped ATM.
In the past, Mondex has claimed that its system offers anonymity. However, Simon Davies of Privacy International has demonstrated that the Mondex merchant system keeps a record of the Mondex account numbers used for each purchase. Despite numerous public trials, Mondex was not widely deployed in the 1990s. It is unclear what the future holds for this technology.
[214] First Virtual might prepend a four- to six-letter word to the beginning of a Virtual PIN for uniqueness.
[215] Double-spending is detected at the bank when a merchant attempts to deposit DigiCash coins. As a result, merchants who receive DigiCash are encouraged to deposit it in the bank as soon as possible.
[216] One way around this obvious problem is to put a code number on the box and send it to a fulfillment house. The fulfillment house looks up the code number in a database and sends it to the end user. In this manner, the merchant knows what is in the box but doesn’t know where it is going, and the fulfillment house knows where the box is going but doesn’t know what is in it.
[217] Some merchants have legacy systems that require the consumer’s credit card number to be on file. It was easier to build this back-channel into SET than to get merchants to modify their software so that credit card numbers would not be required.