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]

Reply via email to