SSL uses public-key encryption to exchange a session key between the client and server; this session key is used to encrypt the http transaction (both request and response). Each transaction uses a different session key so that if someone manages to decrypt a transaction, that does not mean that they've found the server's secret key; if they want to decrypt another transaction, they'll need to spend as much time and effort on the second transaction as they did on the first.
Netscape servers and browsers do encryption using either a 40-bit secret key or a 128-bit secret key. Many people feel that using a 40-bit key is insecure because it's vulnerable to a "brute force" attack (trying each of the 2^40 possible keys until you find the one that decrypts the message). Using a 128-bit key eleiminates this problem because there are 2^128 instead of 2^40 possible keys. Unfortunately, most Netscape users have browsers that support only 40-bit secret keys. This is because of legal restrictions on the encryption software that can be exported from the United States (The Federal Government has recently modified this policy on following the well-publicized cracking of a Netscape message encrypted using a 40-bit key. Expect this situation to change).
In Netscape you can tell what kind of encryption is in use for a particular document by looking at the "document" information" screen accessible from the file menu. The little key in the lower left-hand corner of the Netscape window also indicates this information. A solid key with two teeth means 128-bit encryption, a solid key with one tooth means 40-bit encryption, and a broken key means no encryption. Even if your browser supports 128-bit encryption, it mayse use 40-bit encryption when talking to older Netscape servers or Netscape servers outside the U.S. and Canada.
Not quite. A solid key with two teeth appears indicates that SSL is being used with a 128-bit secret key and that the remote host owns a valid server certificate that was certified by some authority that Netscape recognizes. At this point, however, you don't know who that certificate belongs to. It's possible that someone has bought or stolen a server certificate and then diverted network traffic destined for the department store by subverting a router somewhere between you and the store. The only way to make sure that you're talking to the company you think you're talking to is to open up the "Document Information" window (from the File menu) and examine the server certificate. If the host and organization names that appear there match the company you expect, then you're probably safe to submit the form. If something unexpected appears there (like "Embezzlers R Us") you might want to call the department store's 800 number.
The SSL encryption will take care of network transmission. But we don't want to make it easy for just anybody, even those with access to our system, to view your number. The number is encrypted before ever being written to a file.
First of all, after you enter your number, it is kept in memory only until until it is encrypted. At that time, it is scrubbed from the program's memory. The now-encrypted card number (with the password only known to our order entry personnel) is then written to a file with permissions set so only the program can get at it.
And the program will never send even the encrypted number via the network, only write it to disk.
This behavior will be followed by the MiniVend program as long as the number is placed in a field named credit_card_no -- you can view the source of the order form to ensure that. Your expiration date is also encrypted.
After the number is written, if you actually place the order, the order information will be saved in that file only until we process your order with our ordering system, usually the same or next business day. At that time, the encrypted number will be overwritten with data, to make sure it is wiped from the disk, then the order information deleted.
If you have entered your credit card number and decide not to submit your order, the encrypted number will remain on disk for no more than one day. At that time, the sessions on the system that are older than one day will be expired, after any encrypted credit_card_no fields are overwritten with meaningless data, and removed from the session database.
If you wish, you can press the button on the order form which is labeled CANCEL, and the encrypted information will be wiped immediately.
Answer taken from Alabanza's FAQ:
We use Apache-SSL which is several times more secure than Netscape SSL. Others Use Compromised Security. In a recent announcement, Netscape Communications announced plans to include government back doors in their products. "By implementing this so-called 'key recovery', Netscape is getting a small increase in key length in exchange for putting your keys in the hands of the government," said Parekh. "This the same government that hired Aldrich Ames, the same goverment that has IRS employees surfing taxpayer databases at will. What do you think is going to happen to your keys?"
According to cryptography expert Bruce Schneier, "There is absolutely no business case for key recovery. Any benefit you get from longer key lengths is offset by the enormous security risk of concentrating keys in a few hands." Current "export" versions of Netscape and Microsoft web servers use a weak 40-bit cipher that can be broken in hours by any bored systems administrator or college student with access to a few hundred idle machines. By comparison, all C2Net software can use at least 128-bit keys. To understand this difference, imagine that the hundreds of computers needed to crack a 40 bit key in a few hours were compressed into a cube an inch on a side, and you built a computer the size of the Earth out of these cubes, it would still take this computer more than four times as long to crack a 128 bit key. It's easy to find a few hundred computers idle at any medium-sized business or university; Earth-sized computers are still relatively uncommon.
If you would like more details, please send mail to the .