Paranoid Penguin - Mental Laziness and Bad Dogma to Avoid

Gentle readers, I try not to rant at you, really I do. You turn to my column for practical, reliable tips on getting complex security-related tools to work, and judging from the e-mail messages you send me, most of the time I deliver that.

But, I'm human, and now and then, I get really tired of dealing with mental laziness and dogma. It's not because I'm some sort of purist—quite the contrary. Rather, it's because it's impractical. Each of us security geeks has a limited amount of energy and political capital, and we can't afford to squander it on positions we can't back up with compelling, plausible risk and threat drivers.

Similarly, although I've got tremendous sympathy for nongeeks who strictly use computers as tools, and who find it (rightly) unreasonable to have to know as much as a system administrator just to be able to print their spreadsheets, Internet use has its price. If you're going to comingle your data with that of practically the entire rest of the world, you need to think about risks now and then, and you need to take the time to learn some simple precautions.

So this month, I need to vent just a little bit about some nagging bits of information security dogma to which security practitioners sometimes cling, and some examples of mental laziness in which end users (especially “power users”) sometimes indulge. Your opinions may differ (widely) from mine, and if you take strong exception to any of this, I encourage you to post comments to the Web version of this article or e-mail me directly.

Before I begin the rant proper, let me acknowledge that to a point, dogma can be useful, in the same way that a parent may now and then find it useful to tell a cantankerous child “the answer is no, because I said so”.

Life is short, information security is complicated, and we don't always have the luxury of explaining every rule to every user's satisfaction. Sometimes, it seems to me, it's perfectly appropriate to say, “You can't do that because it violates corporate security policy.” The real question is, “Is that a defensible policy?”

So, perhaps my point is not that there is no place in the world for information security dogma, but rather it's that dogma existing only for its own sake is useless. If we can't back up a policy, practice or other security requirement with compelling, risk-based justification, we will fail.

This month's column, therefore, is about some wrong ideas that have somehow ended up being treated as immutable truth among some of my peers, but whose rationales are questionable and tend to cause more harm than good. And, because I don't want anyone to think I'm unduly biased against my colleagues, I'll give equal time to the aforementioned examples of end-user mental laziness as well.

Consider hapless Hapgood, a typical corporate computer user. At work, Hapgood has to keep track of six different user accounts, each with slightly different password-complexity rules: system A requires a minimum of eight characters containing uppercase and lowercase, punctuation and numbers; system B allows only seven-character passwords, doesn't allow punctuation and so forth.

Due to corporate security policy, within any given 60-day period, Hapgood must change all six passwords—a couple of them twice. If Hapgood starts choosing passwords that are easy for him to remember but not very hard to guess (for example, his own name with a capital H and zeroes instead of Os), can you really blame him?

I wouldn't. But, which do you suppose is more dangerous: choosing a bad password, or leaving a good password alone for, say, 90 days instead of 30?

Naturally, that depends on what you're worried about. If you're worried about brute-force password attacks in which an attacker cycles through all possible passwords for a given user account, then the more randomized the password, the less likely it will turn up in the password “dictionaries” many attackers employ. In that scenario, short password lifetimes will lower the chance that any given password will be cracked before it expires. But, the password shouldn't be very easily cracked if it's sufficiently complex to begin with. So as it happens, enforcing good password complexity rules is a better protection against brute-force password attacks.

What if you're worried about Hapgood being fired, but connecting back into the network via a VPN connection and logging back in to his old accounts, in order to exact revenge? Won't a 60-day password lifetime minimize the amount of havoc Hapgood can wreak?

This question is best answered with two other questions. First, why should Hapgood still have access for even one day after being fired? Second, if Hapgood's accounts haven't all been de-activated within 60 days, what's to stop him from simply changing his passwords once they expire?

Obviously, in this scenario, password aging is the wrong control on which to fixate. The terminated-employee conundrum can be addressed only by good processes—specifically, the prompt and universal disabling of every terminated employee's account.

There's a third risk people hope will be mitigated by password lifetimes—that a password may be eavesdropped over the network, read off the sticky note attached to someone's monitor or keyboard or otherwise intercepted. This risk is probably more credible than brute-force attacks and user attrition combined.

But even here, if attackers can abuse someone else's access privileges for 29 days without fear of detection, there's probably something seriously wrong with how you're doing things. Furthermore, it may be possible for such attackers to install a keylogger, rootkit or other malware that allows them to intercept the new password, once the intercepted one expires and its rightful owner changes it.

Passwords should, of course, have finite lifetimes. User name/password authentication is a relatively weak form of authentication to begin with, and requiring people to refresh their passwords from time to time certainly makes the attacker's job a little harder. But, compared to password complexity rules and good walkout procedures, password aging achieves less and affects end-user experience more negatively.