Security’s First Mistake
Earlier last week, the mighty Joshua Kaufman brought my attention to Jakob Nielsen’s latest alertbox about removing masks from password fields. This sparked some interesting debate, and it got me thinking again about passwords and security in general.
It has often seemed to me that the first mistake people tend to make in applying security is they think more is more. But to paraphrase Burroughs: without analysis of the threat, security can never be a means to any practical end other than simply more security. A wonderful example of this mistake is in Cory Doctorow’s recent Guardian piece about how he and his wife tied themselves up in knots when they tried to work out what would happen to their encrypted hard-drives and network passwords once they died or were incapacitated. The result being almost complete paralysis.
Doctorow is simply asking the wrong question. When applying security to anything, be it a kitchen cupboard or a USB key, you need to ask “is it worth it”? In short, you should not hide stuff simply because you can, you should hide stuff because it needs to be hidden. This seems a fairly simple point to grasp, but then so is the idea that if you eat a lot of food you will get fat – something that clearly confuses many people.
Of course, you might not be in a good position to judge whether something needs to be hidden or not, but that’s a side issue: you should at least try to find out.
Neilsen’s alertbox is interesting because, unlike Doctorow, he’s clearly making a judgement about the threat vs benefit issue, and in doing so is avoiding the First Mistake. In contrast, what could possibly be so important to Doctorow and his wife that terrible (or at least irreversible) things might happen if the contents of their hard drive became known to a third party after their deaths? I point this out because it clearly transcends issues of mere usability, and shows that there’s more to Jakob than meets the eye.
For the record, the above means I’m in favour of unmasked passwords by default, with the option to mask them on demand. The practice of security should be one tenth application and nine tenths risk assessment. All too often it’s the other way around.
I’m a de-mask on demand kinda guy.
Chris Heilmann has written a Greasemonkey script to let you do this now:
http://www.wait-till-i.com/2009/06/26/on-password-fields-masking-and-jakob-nielsen/
Heh – I’ve been using this one for last few days:
http://userscripts.org/scripts/show/1893
I’m sure there will be a large number of variations on all this in the coming months.
The debate triggered lots more thoughts in my mind.
Firstly, I thought that I really don’t care if a login password field remains masked, it’s never caused me any troubles.
Then I thought that where it does cause trouble is when you are setting a password for the first time. Masking here is damn near unjustifiable, and results in those irritating ‘confirm your password’ boxes.
Then I thought about the wider issue of having passwords vs other systems, the proliferation of irritating logins (in e-commerce sites, etc). Like many, I end up re-using the same password across many sites (no, I am not telling), but I get struck by a fear that nefarious person at site A may use my password to hack into my account at site B for nefarious reasons.
Then I thought – hang on, I just gave these people my credit card details, worrying about my password is pretty much pointless in that context.
Oh well – there’s no accounting for fear, it does what it wants.
Interesting point about the credit card details. This is similar to how people think about SSL (if they think about it at all): it’s usually seen to equate with “security” of some kind, yet it has diddly squat to do with the security of data once passed to the recipient.