Ramesh:
The hacker used a flaw in that software where a debugging log was written even when the option was turned off, and the log was set to be readable by everyone, so with a little work on the webserver he was able to read the log, which contained all their transactions.
Supposedly the bug has been known for quite a while and the ICVerify software hasn’t been patched and a lot of businesses are vulnerable to the same bug, though maybe in slightly different ways (depending if the log can be reached through the web server or not.)
Scarrier that that, is the ‘rumor’ (I think it’s true, but it’s impossible to prove) that the company was talking to him about paying, but was afraid of having to justify the payment during an audit. (“And you transfered this money to a numbered account… why?”) There’ve been a lot of cases where banks/etc have paid off hackers, or hushed up cases to avoid the bad press.
Now, on to the how…
The encryption, once properly setup is nigh-invulnerable. It’d take years for a non-megacorp/government level hacker to find one key, and that’d only decypher one transaction.
But, if the software which generated the keys doesn’t use a proper pseudo random number generator (which, because computers are deterministic is hard to do), or if the key is accidentally weakened, by a programming error, or the user hitting ‘aaaaaaaaaaaaaa’ when asked for random text, etc, then this falls apart.
But, even with that, most transactions aren’t at risk because except in the worst cases, the encryption is just weaker, not broken. So this sort of thing is usually attempted on either end of the connection.
Users are easily targetted, I mean, everyone I know ran the Frog in a Blender after (at most) a virus scan, but it could have been doctored to contain a back door letting the attacker later monitor all your actions, including typing in your passwords and CC#.
The stores are often harder to attack, though unfortunately, not as much so as you’d hope. The main benefit is that usually the admins don’t run silly shockwave applets on the secure servers.
But, even a perfectly setup and secured machines is still vulnerable to bugs. I mean, even if CD U. used ICVerify properly it’d still make the log, even if they didn’t let people read it. Then there are a bunch of other bugs in the webservers, the operating systems, and all other software running.
This assumes the admin knows how to set the system up securely, which should mean turning everything off, and turning only some things back on. Many secure transactions servers are also running mail servers, or other non-essential services, which complicate the process. Then there’s the settings for the needed software. Some parts of the files ICVerify uses need to be readable by anyone because they’re the parts users interact with, other parts (this log) shouldn’t be, etc. You have to know the software in and out to know how to properly run it.
What makes this sort of thing worse is the tendency for companies to store all data about people, often using ‘secret’ information as the key, like indexing people by SSN, or storing the credit card number of the customer, etc. This way when a hacker gets in, asside from just a list of customers, they get everything, perfect for ordering a new physical card, or calling in a change of address, etc.
Some countries (I think NZ or AU) forbid the storing of credit card numbers (and other things?) after a purchase. As soon as it comes back approved or denied, that card number has to be wiped from the logs. This is a smart thing. Perhaps the company could keep the first two digits and the last one, so if a customer called, they could verify that the same number was used, without actually storing enough information to cause problems.
But, online transaction, if handled properly, are incredibly secure. I mean, to the point where it’s near impossible for anyone, the admin for the store, or anyone in between, to get information they should have. Contrast this with giving the waiter your credit card… The problem with online transactions is that this desire to store information, and the volume of transactions, make ripe targets. A waiter could get 10-20 card numbers per shift, and would quickly be caught if they were all used, because the common purchase would lead to the restaurant and the waiter. A hacker could monitor Amazon.com or a big store and get 10k cards per day, and if there was a log, perhaps many more.
So, I’d do it. As people say, you are only liable for $50, and most bank waive that, if you show you didn’t do anything dumb, like not call them after your wallet was stolen. There is less direct risk (per transaction) and maybe a bit more (stolen logs) in total, but it’s still fairly secure, and the stakes are fairly small (for the end user… I wouldn’t doubt CD U. goes out of business over this and the inevitable lawsuits.)