On Sat, 21 Sep 2002 10:29:25 +1000, [EMAIL PROTECTED] (Jimmy George) wrote:
>I thought 'encryption' was supposed to make the data transmitted from >user to server into an unreadable block of garbage. Able to be decoded >by the server of course - but of no use to any one else who tapped into >the transmission or the file stored on the server. > >So what's the go? How does SSL make such things as credit card details >secure?? An https connection is totally encrypted. No one on the network in between can see the raw data. The data is encrypted with the server certificate, and you should be able to look at what certs you have with your browser. >The spiel I have just read talks about a 'digest' but all that >is doing is verifying that the information you sent to the user is >coming back unaltered. > >Why send data to a user for them to send back to you? How do I mangle a >credit card number and decode at my end??? You don't need to if using https. If you are not using https, you should not be taking credit cards. However, once the cc number gets into your server, you should encrypt it before writing it to disk, so others on the system, can't accidently read them. The reason people send data to users, just to send it back, and have it verified, is to prevent the "user" from playing tricks. What is someone make an order for 1 widget, at an agreed upon price, you send the page for user verification, and they edit the page to a lower price, and send it back. You need to keep track of what is what. There are other ways of doing this, but they involve writing to disk files to "save the state" of the transaction. The above method saves you the trouble of writing to disk, until the transaction is finalized. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
