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