On Fri, 30 Aug 2002 10:32:27 +1000, [EMAIL PROTECTED] (Jimmy George) wrote:
>Is there any way of encrypting a credit card number etc. so that it can >not be seen when being transmitted from desktop to server? The user >needs to see what they type to make sure it is correct - so how do we >get cgi to encrypt that at the user end before transmission. You don't use cgi to encrypt data on the user side. If you are accepting credit card data, you need to be using the SSL protocol (https instead of http), which sends everything encrypted. The user can enter cc data in the browser, then send to a https address. None of the cc data will be visible in the transmission. If you notice, most online stores will switch from http to https when you check out. Some just run https all the time. There is a developer who is trying a method of Login Authentication with MD5 over http for people who don't have a secure server, it's called Javascript-LoginMD5. It works like this: When you first go to the cgi-script, it sends out a md5 key, which is used by some javascript in the browser to hide the password. It times out after a time delay, like 30 seconds. BUT this is totally inadequate for credit card data. If you try something like that for credit cards, you could be held liable for negligence with the data. If you are running your own server, you need to get a "server-certificate" from someplace like Verisign.Then you can start running a secure server with https on port 443. You can make your own "self-certified certificate", but it is not trusted, because no "external authority" like Verisign has "endorsed" you as being trustworthy. What is to stop people from setting up phony stores with a "self-certified certificates", just to collect credit card numbers? The Verisign people, and their competitors, investigate your legitimacy, then they give you a "signed certificate" to use in your web server. If you are running on a server from someone else, look at their help section for "secure server" or ask the administrator. >I have read some books about it but all we appear to be able to do is to >encrypt the received raw number before storing it so that the file it is >kept in cannot be opened and read. Is that the limit right now? That is the way it is, your cgi program can only do encryptions on the data it has on the server. The encryption during transmission is handled by the "protocol used" either http on port 80, or https on port 443. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
