While we're bothering to educate users, why not explode the "Must Have Encryption on Credit Card Numbers" myth?

For a random person on the Internet, sniffing traffic to get credit card numbers (even if everything was sent in cleartext) is difficult, and doesn't get a very large reward. You'll have to get a machine physically on the network of a router, grab all the traffic (which could be well into gigabytes per day, or even per hour), and anylize all of it for CC nums.

Consider that many companies store the credit card on a machine sitting just outside their main firewall. There could be thousands of CC nums sitting on one of these machines at any one time. Compared to traffic sniffing, cracking into those boxes is often piss-easy (just wait for the next OpenSSH or Windows bug to come along--shouldn't take too long in either case). Those boxes are your main point of security failure, not SSL.

The point about using SSL is that the traffic between your browser and the website is encrypted to minimise the risk of the content being intercepted on route. SSL does not solve any issues relating to storage or handling of the data at either end of the connection.

I am using a corporate network and access the internet via a web proxy. This is a situation that is not unlike being in a internet cafe or using a public wi-fi hotspot. There are people sat all around me using computers to do their work, book flights, buy concert tickets and pay their bills. I therefore could expect to have to 50+ users worth of traffic without leaving my desk. In a non-SSL world, I would probably only need to gather logon traffic for one day to get the passwords etc. and use the information for illicit purposes.

Security starts at home!

inman

I am using a corporate network and access the internet via a web proxy.

Computers that you don't personally own, or do not fully control physical access to, should be considered inheirently untrustworthy. Even with SSL, any network or system admin could probably easily get physical access to any computer in the building and install a keystroke logger. That goes for Internet cafes, too. Putting your CC num into such a machine is reckless.

The security problems of wi-fi networks are well-established. This is one of the few areas where SSL is quite benificial.

I'm not saying SSL is completely useless, just that if we got rid of SSL completely, the security of the entire system wouldn't drop as dramatically as most people think.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

I'm always amazed by how many people think that it really is necessary to store credit card numbers on a system exposed to the net in the first place. Storing unencrypted cc numbers in a database without being *very* careful is just plain dumb.

First, why does no one ever figure out if they ever need to know someone's credit card number again? A while back I wrote a transaction processing program for a non-profit -- the system only ever handles the full credit card number in memory during the course of the transaction authorisation. The log and database only ever store a checksum of the credit card. So it's not hard to demonstrate that the card number was used, but anyone else breaking into the system would end up with a lot of useless checksums (assuming that we've done our checksumming correctly).

It seems to me that you could envision a similar system working even where you *do* need to know the number on a repeated basis...

Two databases are established. One allows read/write/update access to scripts running on the web servier. The other only permits insert/write-only access to the same set of scripts.

The first time a customer places an order data is written to both systems. However, the db with read/update capability only stores a checksum of the card used. The second system stores the actual number (not ideal, but you could combine this with a public/private key infrastructure as well if you were really paranoid).

Future transactions would verify that the checksum was valid in the local database before transmitting the order to the second system for actual processing (which would need the real cc number).

You'd end up with a fairly robust system that could withstand several types of compromise fairly well... I think. Anyone want to poke holes in this?

Most attacks are going to be against the database server itself, not the scripts. So I'm not sure what the privilige seperation buys you in this case. If the CCs aren't encrypted in your database, they're vulnerable.

Personally, I never want my CC to stick around in someone else's database, except for my bank, and only then because they must have it. Amazon's "One-click Shopping" isn't just a dumb patent, it's a dumb idea to begin with. Really, is it such a big inconvience to type your CC number back in? Considering the security you gain by not saving your CC num, it's a very small price to pay.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

If you want to steal credit card numbers get a job as a waiter. :)