By now, you have your catalog, your shopping carts, and you've got visitors gleefully picking products off your CyberShelves. Once they have their baskets full, it's time to check out and pay up-which opens its own can of worms.
The Internet is not secure; but, then again, nothing really is. The final piece of the online shopping puzzle is to try to develop a means for the customer to pay for what they want to buy as easily as they found the product-without having their financial information broadcast to many others. There are several different methods for accomplishing this:
Use a server that supports the Secure Sockets Layer (SSL).
Rely on a virtual bank service.
Use a non-Internet method to complete the ordering. Examples would be mailing a check or telephoning the credit card number to a central site.
When a Web server and browser communicate, information such as HTML documents and form submissions transmits as packets of plain text information. This is primarily to provide a basis that a variety of different machines can interpret. Because the Internet is a massive inter-connected network of computers, there may be several systems between the user's browser and the server, acting as "relays" to get the data between what (to the user) appears to be a direct connection.
This means that someone with some "hacker savvy" could intercept the data flowing through these routing systems and read the data stream. The Internet is not a very secure system.
Security is not just for ordering merchandise, but also for the transmittal of sensitive company information. As an answer to the demand that communications across the Web be more secure, the Secure Sockets protocol was created. With SSL, the packets are encrypted with a keyset established by the server and browser when they first connect. Because only the two systems involved have the decoder keys, anyone trying to intercept the data would see only garbage. The keys themselves are rather large (64 digits), making the possibility of guessing the correct key extremely difficult, if not impossible.
| NOTE |
As has been exhibited on the Internet in recent months, human ingenuity always wins out over intense planning. Even though companies like Netscape and Microsoft have claimed that their encryption schemes are secure, there have been numerous cases where their security has been broken. This occurs most often in an attempt to test the security of the system, not to steal data. As with all security, remember one simple fact: Anything that can be designed by one man can be undesigned by another. To try to compensate for this, both Netscape and Microsoft offer special versions of their browsers that utilize 128-digit keys. While the possibility of cracking these new keys is even more remote, it never hurts to be cautious. For more information on browser and Web security, stop by Netscape's "DevEdge Online" |
Even if you question the security of the SSL, it is more secure than the standard HTTP connection. Therefore, if you plan on accepting sensitive information such as credit card numbers over the Internet, you should never use anything less than SSL to accept the data. As a surfer, you should never give out this information if you're not connected via SSL.
Several companies, First Virtual being one, have created online banks that, when tied with your credit card, provide an account in Cyberspace. Instead of passing credit card information over the Internet, you transmit the PIN for your virtual bank account. Once received, the order request is transmitted to the bank; the bank then sends an e-mail message back to you to verify that you indeed placed the order. Assuming that everything checks out, your order is processed.
| TIP |
You can find more information about First Virtual at their site: http://www.fv.com/. |
From the standpoint of a Web administrator, whether the buyer is using a credit card or a virtual bank PIN should make no difference-sensitive information is still being transmitted.
One method for making transactions secure is to simply not transmit the sensitive information over the Web. Instead, have your ordering system generate a confirming e-mail back to the user with a security code for them to reply to or use to call a specific number.
One of the virtual banks on the Internet, First Virtual, uses a similar system when you want to create an account with them. It is as follows:
This way, your customers never transmit critical information over the Internet.
To implement an e-mail requestor, you use a form (as before) to submit the bulk of the order. However, instead of asking for the user's credit card information, you generate a unique "order confirmation code" that you e-mail to the user. To generate the code, you can use a code fragment similar to the block shown in listing 20.1.
Listing 20.1 Generating a Random Character Sequence
srand($$|time);
@saltchars = (A..Z,0..9);
for($i=0; $i<10; $i++) {
$code = $code . $saltchars[int(rand($#saltchars+1))];
}
The call to srand() seeds Perl's random number generator-in this case, with the current system time. This sets up the rand() function to dance through the array of possible characters for the code, pulling one at a time and concatenating it onto the end of $code. When finished, you have a 10-character random code.
While this should provide a code that's unique enough (that is, one that couldn't be generated again because of its random nature), it is possible, though unlikely, for the exact same sequence to be produced at some time in the future. To circumvent this, storing used codes within another file and checking the generated code against those that have already been used is a good idea.
This chapter looks at several different methods for completing the shopping process of getting money from the customer. For more information on the various tricks and tips demonstrated, check out: