Re: Credit card and 15C Message #18 Posted by Les Bell on 21 Sept 2011, 11:50 p.m., in response to message #2 by bill platt
Quote:
I am convinced that many of these so called "secure" sites are totally hacked. I also fail to understand how there can be useful "encryption" when the key obviously has to travel with the rest of the data--it isn't like there is a password coming by US mail first!
Most merchants who accept credit card payment online have to comply with the PCI DSS (Payment Card Industry Data Security Standard) requirements. These are fairly prescriptive, rather than talking in general terms - e.g.
Quote:
"3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
* One-way hashes based on strong cryptography (hash must be of the entire PAN)
* Truncation (hashing cannot be used to replace the truncated segment of PAN)
* Index tokens and pads (pads must be securely stored)
* Strong cryptography with associated key-management processes and procedures
(PAN = Primary Account Number = credit card number)
Most small merchants can self-audit, but would find the compliance requirements too burdensome, while larger merchants have to undergo and audit by a qualified assessor. For these reasons, many merchants prefer not to handle credit card numbers at all, but instead hand off the payment processing to an external provider (their bank, PayPal or some other service provider) whose pages may (or may not) be branded with the merchant's logo & color scheme, etc.
I ordered a 15CLE from Samson Cables, but didn't notice whether they did this; however, I did just check and see that they provide a "secure contact form" via an external provider and expect that they handle CC processing the same way.
As a result, even if a small site is "totally hacked", there are generally no credit card details there to be compromised.
As to what is known as "the key exchange problem" (how does Alice get a key to Bob without Eve [the eavesdropper) getting it?), public key cryptography solves that. When your browser enters SSL/TLS mode, it fetches a certificate from the web site which contains the site's public key, checks out the certificate and extracts the public key. It can then do one of two things:
a) either generate a short-term session key and encrypt it with the web site's public key and send it to the site (where the private key is used to decrypt it, or
b) use the Diffie-Hellman Key Agreement Protocol to arrange for both ends to come up with the same session key, while an observer can't deduce it.
Which technique is used really depends upon what the web server software is and how it is configured. Either way, all subsequent data is transferred using symmetric cryptography (for speed) in both directions. (I've simplified the actual TLS protocol, but this is basically how it works).
(I teach this stuff at the university where I'm doing my PhD).
So, I wouldn't panic, and I wouldn't worry too much about shopping online. It certainly wouldn't stop me ordering another 15CLE if I needed one urgently!
Best,
--- Les
[http://www.lesbell.com.au]
|