|
|
A lot of attention has been given to taking credit
card orders on the Web. At the time of this writing (May, 1997),
the technology needed to implement credit card orders on a Web site
has gotten fairly straightforward and economical. But credit card
orders are mainly for consumer purchases. What about business to
business purchases? These are generally handled through purchase
orders. And here's how that can be done.
A purchase order is an authorization by a company to spend money
on a specified set of products. The purchase order may specify
how much can be spent on the products, negotiated prices for the
products, who in the buying company is authorized to make the
actual purchase decisions and what the payment terms shall be.
If a purchase order authorizes a number of transactions over time,
one must keep track of how much has been spent to date and what
remains in the purchase order account.
When a company accepts a sale through a purchase order it must
check a purchase order database to identify the purchasing organization,
the purchasing individual, the current level of the account (versus
the amount of purchase) and special negotiated prices. To do this
on a Web page means maintaining a database of this information
on the Web server. And that's the trick: making such (moderately)
sensitive information available to the script that processes an
incoming order while keeping it secure from prying eyes.
The most reliable security measure that one can take in any
situation is to risk as little information as possible. Perhaps
all pricing for Web purchases can be uniform across all customers.
If so, special pricing arrangements need not be stored on the
Web site. Are current balances really necessary at transaction
authorization time? If the items being sold are inexpensive enough,
it may be sufficient to update the purchase order database after
each transaction, not in real time. That way the Web database
(the one vulnerable to attack) holds a list of customers with
open purchase orders but not the remaining value for each purchase
order. If a purchase order is open, the sale is authorized. The
product is delivered. A process inside the company (on a secure
database) records the transaction, subtracts the purchase amount
from the purchase order balance. If the new balance is zero, the
purchase order is then removed from the Web database.
Minimal information on the Web purchase order database is Customer,
Purchase Order Number, and some authentication code. The important
thing to note is that one need not identify what this information
is, only that the customer can properly match it. Here's how it
would work.
- Prior to coming to the Web site, the customer has opened a
purchase order with the selling company. The selling company
has added that purchase order to its database of open purchase
orders.
- The customer selects items he wishes to buy. When ready he
says he wants to check out, he is asked to fill out a form asking
for his company, purchase order number and username and password.
- The information he enters is sent to the server.
- When the information arrives at the server it is encrypted.
- All information in the database is stored in encrypted form--using
the same encryption algorithm as that used in the previous step.
Now, the encrypted values the user entered are compared to the
encrypted values in the database. If there is a match, the user's
purchase is authorized. His company, purchase order number,
username and password have all been verified without revealing
to prying eyes on the Net what those values are.
Now some variations on the theme. First, when the user enters his
purchase order information into a Web form and it is sent to the
server, it should be encrypted in the ordinary way it would be (using
the SSL protocol) between a secure server and browser. This prevents
prying eyes from seeing the information as it crosses the Net. (Note
that this encryption step is separate from the encryption mentioned
above.)
Second, we can add business rules for negotiated pricing to
the database. Customers and purchase order numbers could remain
encrypted, only the rules for negotiated pricing would be available.
Is there risk in this information? Not much. Just that some unspecified
customers are able to negotiate different pricing arrangements.
If the site offers special pricing per purchase order, clearly
the customer must identify himself to the server before he starts
shopping...so prices while shopping will reflect the special pricing
negotiated with the PO.
Third, we can add the remaining balance for each purchase order
to the database. The risk would be that, if stolen, a hacker would
be able to sum these balances and see the total of all open purchase
orders that apply to the products offered on the Web. Probably
not a major security breach even in the unlikely event that someone
was able to break into the database and steal its contents.
Purchase order authentication as described above can occur in
real time as a customer places an order. If an information product
is being ordered, download can begin immediately. Behind the scenes,
a record of the transaction is sent from the Web site to accounting
systems inside the company where the actual charges are settled
against accounts and modifications to the purchase order database
are made.
©1997, Harry Tennant & Associates |
