Security: Perceived Risk versus Potential Damage
All too often, while running the PHP forum on The Scripts, I see students working who are completely ignorant of the security concerns prevalent with the systems that they build. Worse, when alerted to the potential dangers associated with poor programming practices, these coders let loose a variety of excuses why their application doesn't need to implement a security policy. Ranging from "this is a low traffic/internal site" to "I'm doing this as a project for school, so security really isn't an issue." In my eyes all explanations are equally irrelevant. As leaders of the forums, my colleagues and I daily battle assertions about the validity of these concerns.
Ultimately what one should focus on is not the perceived risk, but rather, the most important factor in any security system is the potential damage. If the level of risk is very low, either because the system is a low traffic site, or based on an internal network, that is still no reason to offset it with a low barrier of entry. Instead of assessing the likelihood of being hacked (which is far larger than most would guess), one must analyze the potential damage that a breach may cause. If someone gains elevated permissions and executes a DROP DATABASE on the back-end, is your system royally screwed? If someone gets a dump of the information held in the system, how much information about the system and your clients have they gotten ahold of? Can the information stored in the database be used to deal further (financial, emotional, or physical) damage to its users?
To drive home the potency of this situation, here is a hypothetical situation:
Company Co. is working on a companion application to the popular music software iTunes. The program is currently in open Beta and users can sign up and use the application for free, but it is still undergoing development. The software itself is nothing spectacular; as a companion to iTunes, it indexes your music library and matches your tastes in music with other users who listen to similar music. Not much information is kept about each user, only an email address, password, and list of songs on the user's computer, so security is not a high priority on the developer's todo list. For the time being Company Co. has opted out of SSL between the application front-end and the front-end server. In order to aid in the debugging process, passwords are stored as plain text in the database, and to improve the user experience, username and password are stored locally to expidite the process of logging in. The developers were not fools, so there is a tiered architecture between the application and the database; all connections are run through an application server, and the database is kept from outside access because it has no external IP address.
The application described above certainly does not sound secure, but it is in beta testing and most of the people using it have heard about it through word of mouth or from the developers directly. The end user most certainly wont be stealing their own passwords from the file on their computer, will they? And if a user has someone sneaking on to their computer and stealing files, they have a bigger problem than just a password kicking around! If the user happens to fire up the application on a laptop in a public area, what have they lost? Do they really care that that geek in the corner knows they listen to Justin Timberlake? Big deal!
While driving through the city, a kid decides to fire up the old laptop to see what movies are playing. Pulling into a parking lot, the kid quickly sees that Company Co. has a WEP encrypted wireless network. No worry for the kid though, there is a lot of traffic, so getting the IVs takes not more than a couple of minutes. Spiderman 3 is playing at the second run cinema, but while the laptop is running, why not fire up ethereal for kicks...what is this? The kid notices a lot of plain text traffic kicking around: curiosity must be its own rewards, so the kid investigates. After seeing a number of email addresses and passwords flying around the kid stumbles upon the yet to go live web server with an active download for the software. After a quick install and a bit of playing around the kid decides to test one of the logins snagged earlier against, not to the software, but to iTunes itself. Worked like magic: this user was lackadaisical in choosing passwords and used the same user name and password combination for both iTunes and the companion software! Pressing the user's credentials further the kid fires up PayPal and logs in successfully as well. Depending on the attack vector, the vulnerabilities in this software can have a ranging scope of destruction. Sniffing at the user's end results in a user's credentials being compromised, while sniffing at the server's end results in a larger number of users having their information revealed. Further still, were the database to be compromised, the entire user base would be subject to damage, through the various online banking institutions.
This danger does not lie solely in the imagination of security analysts and hackers. This threat is real. TJX lost over $1 billion out a wireless router which was set to use WEP security. Companies do store passwords in plain-text. People do use the same email address and password for multiple sites. Kids can read traffic as it passes through those beautiful tubes called the internet. The moral here is this: it is not the information that you hold, but rather what that information means to the people whom it is about.
For further reading on the matter, Dark Readings had a sobering article titled Small Business: Hackers' Low-Hanging Fruit. Webroot has a companion article about the unseen risk that SMBs are subject to. You can find out a little more about the TJX breach here.
comments powered by Disqus