The fuss over accountability for bad code

Who should pay when poor coding damages customers? The hornet's nest poked two weeks buzzes on -- and an example of lazy coding helps clarify the issue

I really wanted to write about something else this week -- say, about how VMware is aiming a shotgun at its feet with its new licensing scheme -- but my last two posts ("It's time to make poor coding a felony" and "Why those guilty of bad code must pay") have taken on a life of their own.

I continue to be inundated with opinions from all sides about the issue of accountability for customer data leaks. At first these comments were mostly negative, but the field has broadened. At this point, as many people seem to agree with me as think I'm a lunatic or not very bright. As far as I can tell, the majority of that latter camp either didn't really read my posts or are in fact the very same development managers who approve and push products with glaring security holes at their core.

[ Join Paul Venezia for a Twitter chat, hashtag #acctablecode, on Thursday, July 28, from 2 to 3 p.m. ET. | Also on InfoWorld.com: Read the posts on accountability for bad code that started it all: "It's time to make poor coding a felony" and "Why those guilty of bad code must pay." ]

In fact, these two posts have garnered so much attention that I'm going to run a "live" Twitter conversation about this very subject on Thursday, July 28, 2011, from 2 to 3 p.m. ET. We'll be using the hashtag #acctablecode, so if you want to be part of the debate, fire up your Twitter client of choice and dig in.

As this discussion rolls on, allow me to provide a specific example of what I'm talking about from a ground-level perspective. Consider these two MySQL query samples (let's assume the input variables have been sanitized):

SELECT id, email, passwd, status, first, last FROM users WHERE email = '$sessemail' AND passwd = SHA1('".$form_password."');

SELECT id, email, passwd, status, first, last FROM users WHERE email = '$sessemail' AND passwd = '".$form_password."';

The only difference between these two queries is that the first uses SHA1 hashing on the password and the second doesn't. While using an SHA1 hash on a password won't guarantee the password can't be cracked, it makes it much harder for anyone working with a dump of this database to retrieve the actual password. Even if it took only 10 seconds to match an SHA1 hash for a terrible password like "mypassword," you're still lengthening the time required to reveal the user's password by 10 seconds over the plain-text equivalent, which is zero seconds. Multiply that 10 seconds by the thousands or millions of passwords in a compromised database, and the likelihood of a widespread identity theft problem stemming from a single exposed database drops dramatically.

1 2 Page
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies