james mckay dot net

Website logins scare me. It’s frightening how many incompetent and/or lazy and/or irresponsible web developers there are out there who see nothing wrong with storing passwords in plain text in a database, and even worse, give attackers wiggle room to find them by peppering their code with SQL injection vulnerabilities.

Unfortunately, with so many different websites implementing their own login systems, inevitably you have to create dozens of different accounts. And to get round this, pretty much everyone re-uses their passwords all over the place.

The result of this is that if you register on, say, a Christian dating website that subsequently gets hacked, you run the risk of your Facebook account being compromised.

But it simply isn’t practical to have a different password for every site you register on.

Or is it?

Recently I decided to do something about it, so I downloaded and installed KeePass. It’s a Windows program that keeps all your passwords in a strongly encrypted database, allowing you to have different passwords for every site where you have an account, and make them as strong as the site will allow. It has an auto-type feature, where you can get it to enter your user name and password into a web input form for you, and there is a version that you can save on a USB key disk and run on any computer, even if you don’t have administrative rights on it.

With a tool such as this, you can make your passwords as strong as you like. I set the password generator to choose 25 character passwords containing any kind of character that it’ll give me: letters, numbers, punctuation marks, brackets, you name it. Passwords such as these would keep all the computers in the world guessing well into the Degenerate Era.

I’m now trying to remember all the websites where I’ve ever registered an account, so I can change my password on all of them. I’ve done all the high risk ones that I use regularly, such as my bank, my web hosting, Facebook and so on. Google has been jogging my memory on various other ones — some of which I had forgotten even existed.

Comment on this »

Posted at 08:00 on 30 November 2009.
Tagged: KeePass, passwords, security, SQL injection

The Christian dating website that got hacked by 4chan back in August was a textbook illustration of why you should not store users’ passwords in plain text. Most of the users of the site had re-used their user names and passwords on Facebook and their e-mail accounts, which were compromised as a result, in many cases in extremely embarrassing ways.

Reading about this (and a similar event somewhat closer to home a week later) has got me thinking about the whole issue again. A couple of years ago, Mats Helander proposed on his blog that saving plain text passwords should be illegal. (Unfortunately he lost his domain name to squatters a few months later, but the post is still up in the Wayback Machine.) His post was in response to some of Jeff Atwood’s readers, who pointed out that many web developers have bosses and clients who insist on them storing passwords in clear text so that they can e-mail password reminders to their users. To be sure, you can try explaining to them that there are alternative approaches that don’t compromise usability, but if your boss is an “I’m not a computer person” type, or just doesn’t care, you might as well try to strike a match on jelly, or you may even find your job on the line. However, if you could tell your boss or clients that they were asking you to do something illegal, you’d be in a much stronger position to push back.

Now I am not a lawyer, but the other day, I took a close look at the Data Protection Act 1998, and if I understand it correctly, saving passwords in clear text is indeed illegal here in the UK.

The relevant part of the Act is Schedule 1, Part I, paragraph 7, which states the seventh of eight Data Protection Principles:

Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

This is expanded on in Schedule 1, Part II, paragraphs 9-12, which tells us how to interpret this principle. Paragraph 9 in particular says:

9 Having regard to the state of technological development and the cost of implementing any measures, the measures must ensure a level of security appropriate to—

(a) the harm that might result from such unauthorised or unlawful processing or accidental loss, destruction or damage as are mentioned in the seventh principle, and

(b) the nature of the data to be protected.

It should be noted that these restrictions apply to “personal data” as well as to “sensitive personal data.”

As Mats argued, and I would reiterate, and the Christian dating website/4chan incident illustrates dramatically, losing people’s passwords has the potential for immense harm. Defacing Facebook profiles can cause serious embarrassment and possibly even wreck careers, but if the attacker then gets access to your e-mail account, they can obtain or request new passwords for even more sensitive websites such as your bank, your credit cards, and so on.

It seems obvious to me that storing plain text passwords in a database most certainly does not “ensure a level of security appropriate to the harm that might result from such unauthorised or unlawful processing or accidental loss” as required by the law. The state of technological development provides us with a much better solution — a one-way salted hash, which is computationally infeasible to reverse engineer — and since there are still perfectly adequate solutions to the login recovery problem, the cost of doing so is negligible.

I’d be interested to hear from anyone who specialises in the legal issues surrounding computer security whether my understanding of the Data Protection Act is correct here. Do you concur with my conclusions? Or do you think that the law need to be made more explicit on this matter?

Comments (2) »

Posted at 13:00 on 16 September 2009.
Tagged: best practices, Data Protection Act 1998, law, passwords, security