Security is your responsibility

I recently read a story that made me contemplate the relationship between website developers and the visitors to these sites. I’ll share my most obvious conclusion here.

The social implicit contract

When building a website that you expect people to use, you are implicitly entering into a mutual agreement with that website’s users: You expect the users to use your site, and they in turn expect you to take them seriously. In particular, they expect you to store their personal information reliably and inaccessible to others. This holds true even if your website doesn’t actually contain any confidential information per se. As soon as you have users, you have logins and passwords that need to be protected.

But if my site doesn’t contain confidential information, it matters little if a user’s account is compromised

you may say. However, that is just plain wrong. Users will most likely use the same username and password in multiple places. Thus, if a user’s password is compromised because of a flaw in your software, who knows what other systems you may inadvertently have compromised.

But best practices recommend that users never reuse a password. If they do, it is their own fault and they alone must face the consequences.

Not so fast, sailor. The fact of the matter is that the average person has a multitude of online accounts with various services and that it is utterly impossible for him/her to keep track of a similar number of unique passwords (let alone of which passwords goes with what service). To this day no one has really solved this problem.

Thus, you should expect people to reuse passwords and protect these passwords accordingly. Having a laissez-faire attitude to users’ passwords means you’re not doing your job properly. Period.

I’ll say it again:

 

You, yes you, need to store passwords securely

 

A compromised password in one system, no matter how insignificant, may have dire consequences for other and much more critical systems. Since Internet users invariably reuse passwords, web developers collectively need to protect these.

I realize that being a security specialist is a full-time job and that most developers don’t have the time to become experts in this area. However, I think every web developer who is worth his salt should at the very minimum

  • understand the most basic attack vectors like SQL injection attacks and cross-site scripting attacks and how to mitigate these
  • know how to properly store a password (or, better yet, avoid building a password system but use someone else’s)

I’ll end this post with the illustrative tale that inspired me to write it.

The HBGary attack

There was once a security firm called HBGary (at the time of writing there still is). This was a reputable company providing training and malware protection software to Fortune 500 companies and high profile organizations.

In its quest to rid the world of Internet scumbags, it one day happened upon a group of anonymous scoundrels and threatened to expose them. HBGary barely lived to regret it.

The scoundrels exploited a basic SQL injection chink in HBGary’s armor and leveraged this weakness to open a floodgate for attacks on the organization: HBGary’s emails were publicized, their data, including backups, were destroyed, and their website and twitter profiles were defaced.

For the unabridged story, read the inside version.

What do you think? Which implicit responsibilities do we as web developers take upon us when we deliver a product?


  1. john says:

    Hi, I stumbled across this post. I’m not a web developer, and I am guilty of sometimes reusing passwords. Do you have any ideas of how a person could be safer without having different pws for every site?

  2. rune says:

    @john: You could use some form of password manager. A password manager will allow you to have different passwords for every website, while still only having to remember one password (http://en.wikipedia.org/wiki/Password_manager)
    If you are a Mac user check out Apple’s Keychain (http://en.wikipedia.org/wiki/Keychain_(Mac_OS) ).
    On a Lenovo Thinkpad you could use the Client Security Password Manager (http://www.pc.ibm.com/us/think/thinkvantagetech/security.html).

Leave a Reply

*