Re: My credit card details have been sent in the clear!

From: Jim Kreth (jim_at_krethweb.org)
Date: 12/04/03 

Date: Thu, 4 Dec 2003 10:29:18 -0800

The SSL protocol uses the "Servers" key to perform a handshake with the
browser. The net result is a session key (symetric key known by both the
server and browser) that is then used to encrypt traffic going in both
directions until the session is killed. In order for someone to capture
your data, they would need to record all the traffic between broswer and
server, crack the session key (128-bit SSL takes a LOT of cpu time to
crack), decrypt all the traffic and then find the particular bits that make
up your CC number in the stream.

Make no mistake, this can be accomplished and you can bet the NSA does it on
a regular basis. The issue really comes down to: Are the bad guys smart
enough to do this and if they are, is it really worth the effort when
dumpster diving behind a nice restraunt is easier and yields better results.

Jim

"Richard" <qaz1521@hotmail.com> wrote in message
news:bq3kcc$q5c$1$8300dec7@news.demon.co.uk...
> If there is a little yellow padlock at the bottom right of the browser,
then
> data is encrypted during transmission. I don't know the exact details but
I
> believe that the encryption is based on keys on the web server, rather
than
> on your client.
>
> Anyway, your credit card number is exposed every time you hand over the
card
> in a shop or restaurant. It's much easier for somebody to copy the number
> when you are present than to capture card numbers off the Internet.
>
> Richard
>
> "Giulio Cespuglio" <guilio@despammed.com> wrote in message
> news:62cdd6cc.0311261534.4b084f92@posting.google.com...
> > Should I worry?
> > What are the odds of my details being sniffed and used?
> > Could you point me to some literature please?
> >
> > In case you are curious, the problem is that an online retailer has
> > sent back to my browser my details for confirmation - including full
> > credit card number and expiry! I don't know much about SSL, but I'm
> > pretty sure that, since the seller cannot know my public key, the
> > information they send back is not encrypted. Am I wrong?
> >
> > Thanks a lot for your help.
> >
> > Regards,
> > Giulio
>
>

Relevant Pages

  • Re: Attempt to de-mystify AJAX
    ... "Hyperlinks" always open a new browser window. ... What I meant is that the server, from its state tables, can easily determine ... >>> around cookies and JS, but it seems to be tough. ... >>> 1) use cookies to maintain the session key and hope that the expiration ...
    (comp.databases.pick)
  • Re: FOLLOW UP - Re: what certificate to buy from Verisign ?
    ... If you use SCT it goes something like this: ... Session key exchange using Certs to exchange and verify identities. ... Server caches the SCT using SCTID is unique id. ... > SSL handshake is an expensive operation, if I choose to use SSL to access ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: FOLLOW UP - Re: what certificate to buy from Verisign ?
    ... > Yes, when calling webservice which is SSL protected from cilent proxy, the ... > usually in a server to server scenario, once response is received, the ... >> handshake is done, and a session key is established, session key is ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: encrypt password for webservices
    ... Everything that reads 'SAL' in my previous post should be 'SSL'. ... > uses a session key to encrypt data. ... > of a Web client and a Web server. ...
    (microsoft.public.dotnet.security)
  • Re: FOLLOW UP - Re: what certificate to buy from Verisign ?
    ... \par usually in a server to server scenario, once response is received, the ... \par SSL handshake is an expensive operation, if I choose to use SSL to access ... \par> Microsoft Online Support ... \par> handshake is done, and a session key is established, session key is ...
    (microsoft.public.dotnet.framework.webservices.enhancements)