Saturday, August 4, 2007

Website security and stolen data

So today I got a call that few like to get....

A company I bought some products off advised me that they'd had their data stolen and my credit card number was among the list.

At first I was more bothered because of the late time of the call, I felt sorry for the poor guy trying to run a small business and now having the unenviable task of needing to call all his customers. I mean, it's inconvenient having to cancel my credit card (thank god no dodgy transactions had taken place yet) but really not a lot of harm has been done. I guess there is potential for harm still as the people that collected the details could use the addresses to stake out local residents and wait for the new cards to come in (but I would think this was an offshore operation).

The worse thing is that most people use the same, or similar username/password crudentials for all the accounts the have. This worried me a bit but I realised that only a couple of not very important accounts were the same.

I was quite surprised that this occurred because the website certainly looked professional, had the usual "secured by whatever images", was standards validated and had the processing taken care of by a merchant site (which are usually quite good with security). Only after the fact did I come back and read the the privacy policy and found that credit card numbers and other information was stored by the website itself with the reasoning to do with speeding up error tracking or transactions that were knocked back.

Personally, I would do anything possible to not require credit card information to be stored in the site database. It's just too risky. People also tend to trust the magic padlock too much, SQL injection attacks can still occur over https connections. In fact it makes it harder for intrusion detection software/hardware to track because all the transmissions are encrypted.

I also noticed that the site was done in PHP. Don't get me wrong, I love PHP and think it's great for quickly getting sites done and the number of really good frameworks available for it is awesome. But the problem is that if the developer doesn't have a good grasp on security techniques/methodologies, then it can leave a lot of holes open as the default security isn't great. It's not the fault of the language, just it's use in the implementation.

I tend to prefer inherently more secure languages nowadays, especially ColdFusion if you haven't noticed by the previous posts. I have to use it at work and have come to really appreciate it. It is very well structured, has introduced a lot of OO features, has great validation functions, deals with datasources like nothing I've ever known and can integrate with Java or .NET components now too. It's not perfect and using tags for everything can get annoying (although there are cfscript tags for writing stuff that looks more like actual code and many functions that feel java-ish too :) but overall I recommend giving it a try. Very easy to pick up.

Man I've gone off topic... oh well

No comments: