November 1997
An editorial from our webmaster:
I have read much nonsense on this topic recently. Some of the worst nonsense was in a PC magazine article (Evolving Internet Security Methods -- April 23,1996). I decided that some straight talk should clear the air a bit.
First. Forget the net. The most serious security problem with a credit cards is that anyone who looks at the information can also use the card. So the biggest risk using a credit card is to hand it to a clerk or waiter. Any problem using it on the internet pales in comparison to that first risk. Debit cards are much more secure in this sense since they require that you enter a pin number to activate them. Your chances of having your debit card rip-you-off are correspondingly lower than a credit card.
Second. The problem with credit card transactions on the net is not individual transactions. The risk for an individual on the net is the same as the risk of using your card in person, that is, the person you give it to will misuse it. Snooping on the net is difficult, snooping in person is easy.
The real problem for the internet is reduce the reward for snooping so that MASS fraud won't occur. That is how does one prevent somebody from filtering all traffic on the net looking for credit card information and recording it? Then using the massive credit card database he has built up the thief can get whatever he wants... a little at a time from many different cards. Individuals would probably get small to medium size thefts, but the thief would get a bonanza. Banks are not keen on this happening, because it would be hard to trace and stop. No one would really know if any given card had been compromised. So it is essential for the banks to have credit card transactions on the net protected.
Encryption of net transactions is the answer. It changes an individuals risk only slightly, because our mass fraud thief wouldn't probably hit anyone too hard, and the in the US, the banks take that hit anyway, at least they do if you detect the theft and complain. Encryption of net credit card transactions prevents anyone from making a big haul from sniffing many internet transactions; the thief just can't economically read the encrypted traffic. With encryption the individual still has to trust the person who gets the credit card information -- if he or his employees misuse you card you are still in trouble. But that risk is the same if you give the card to a waiter, no more, no less.
Encrypted transmission is accomplished on the web by using a secure server. The little key in the Netscape browser will be compete rather than broken. In Microsoft Internet Explorer the lock will be locked rather than unlocked. It indicates that the browser is talking SSL on the net and encryption is being used. The site name will begin with https://...
Sometimes I hear arguments about 40-bit vrs. 124-bit encryption. These arguments are stupid. They have nothing to do with the SSL technology; they only deal with US government policy. Yes, it is true that 40-bit encryption can be broken with enough CPU power, but using it is mandated by the US government so they can snoop on you and on international transmissions to and from the US. This is complete nonsense. Overseas there is usually no limit on encryption, so most of the world is using stronger encryption than people in the US. Recently 124-bit encryption has been authorized locally and for export in bank transactions.
In any case, for mass fraud to take place 40-bit encryption will stop the crooks dead in their tracks, because it will cost so much cpu-power to break all the transmissions and discover credit-card numbers that if they had the money to buy the equipment to snoop they wouldn't bother, they would just go spend it. The government also has enough money to buy what it wants, so you might as well let it snoop as there is little you can do about it anyway.
Third. There is one last issue... authentication. How do you know that the company you are dealing with is in fact answering the net communication. When you deal in person you are sure because you are there. On the net where you are is never clear.
However, there is already a pretty good answer to that question. Verisign Inc. issues server certificates which identify the company that is operating the server you are dealing with. If you are talking to a "secure site" using your browser, then the properties of the site will tell you who the owner of the site is and who certified that site. There are some standard certificate authorities installed by Microsoft and Netscape in their browsers. If one of these has issued the certificate then you can be pretty sure you are talking to the real McCoy.
The other half of the that problem is: How does a company know that you are you. That is that you (the person) own the credit-card you are using. In person, they can check your id-card to make sure you are you. Although I must say this is rarely done at any restaurant that I have been in. It has happened to me once in a liquor store, out of hundreds of transactions. But the internet is a little different. It is like being in the dark, somehow it is easier to pretend to be someone else in cyber-space.
The solution to the authentication problem is to have someone offer "id-certificates" to individuals to put in their computers to validate their identity. This personal identification is just getting started. Verisign Inc. offers certificates that link an email address to a name for $10/year. You can get them free from Thwaite Consulting in South Africa. These certificates are pretty weak because the email address can be attached to any name you want. It is hard for a company that is not local to you to check your identity.
For people in Southern California, ServeNet Certificate Services offers a full id-certificate. They check your id in person and then issue a certificate that establishes that you are who you say you are. They offer this service because they need it to validate their own clients, but they also offer it as a general service to anyone who drops by their office in West Los Angeles with their passport, or California Drivers License, and fills out our questionnaire. The cost for personal id's is $25/per year. Foreign nationals get a 40-bit key and locals and those with a green card get a full 128-bit key.... US cryptography export rules.
Back to the PC Magazine article, Evolving Internet Security Methods -- April 23,1906, by Tony Pompili. He first discusses firewalls which have really nothing to do with the problems as I have outlined the issues above. Firewalls are a way for companies from keeping unauthorized people from accessing their computers and also keeping employees from looking at sex sites while they are on the job.
Then Tony talks about SSL in confused way. SSL is Netscape's Secure Socket Layer and it is the method that browsers encrypt and send messages on the internet. He seems to confuse passwords and log-ins with SSL... they have nothing to do with one another. SSL can use a local password to protect your private key. The certificate that is issued to you is public, just like an ID card. The certificate is used to create the secure connection with the web site you are talking to. Neither your password nor your private key is ever put on the web; they stay local to your machine, this is true even when you apply for a certificate.
Then he seems to indicate that it isn't only web site access that needs to be protected, ftp and telnet (or logon) access should also be protected. This is of course true, and SSL does it all of it. He seems to think it doesn't. Then he implies that SSL is proprietary to Netscape, and if you use it you have to license it from them. This is clearly untrue. The Netscape site states: "The license restrictions for this reference implementation have no impact on anyone's ability to freely implement the SSL protocol purely from the SSL specification." In fact there is a public domain library supporting the SSL 3.0 specification called SSLeay developed in Australia. So SSL is freely available to anyone who wants to implement anything in it.
Finally, he concludes his article by saying that SSL does not satisfy the US government. That they are planning an alternative approach called Fortezza. Fortezza handles the authentication problem by issuing "smart cards" to people as ID cards. These cards must be placed in hardware attached to your computer and they identify you to the machine and the internet. Fundamentally this is exactly the same as SSL certificates except the certificates are held on separate hardware that you can carry with you.
The government is probably not happy with SSL because it is too strong rather than too weak. It would clearly prevent them listening in on internet communications.
This smart card is a great idea, and when every machine comes with a smart-card reader then it will work fine. Hopefully it will contain certificates offered by non-government certificate authorities. Before that happens we will have to settle for a little less security. Of course with the US government's record on wanting to read all communication, I think I would rather trust SSL than a hardware smart card that the government offers me.
BUZ
Webmaster, ServeNet
© 1997 Robert Uzgalis. All Rights Reserved.