It was just a fluke that we ran a password audit last week on our own domain and that of a subsidiary with which we have a full two-way trust relationship. I was disheartened after looking at the results of the report. I called the security team together and said, "We might as well go home. There's absolutely no point in banging our heads against the wall any longer."
Why was this password audit a fluke rather than a regular security measure? The fact is that we have so many things on our task lists that sometimes the most obvious part of security is overlooked. We suffer from a lack of staff, lack of tools, lack of time, lack of security awareness and lack of security policy enforcement. And being new to the company, I made a fundamental error in assuming that the stated password policy, which had been signed off on by executives and posted on the company intranet, was actually being enforced by IT across our domain and those of our subsidiaries.
In a way, my awareness of the importance of secure passwords made me blind to the problem: Since I care about my password being cracked, I chose a secure one, and so I didn't stop to test the password policy.
We're back to square one. Without a properly enforced password policy, who cares if the firewall is logging properly, the SQL Server password is blank or our patches are up to date? Passwords are the first line of defence.
In a Windows network, the password policy is set at the domain level, and in our environment, that's managed by Active Directory. Our current password policy includes these provisions:
- Ten passwords are remembered, which means you can't reuse a password until you've chosen your 11th.
- Passwords expire after a maximum of 45 days.
- The password must meet "complexity requirements": They can't contain all or part of the user's account name, they must be at least eight characters long, and the characters must be chosen from three of four categories - English uppercase characters, English lowercase characters, base-10 digits and non-alphabetic characters such as !, $ or #.
All this sounds good, but the policy isn't strict enough, and it allows for passwords like Password1 and Password2. Is anyone surprised that we found these types of passwords on the network?
When I got the list of users whose passwords had been easily cracked, I looked for key executives, domain administrators and other potentially risky log-ins. I found them all, including some highly visible executives with very stupid passwords. My first order of business was to e-mail one of the domain admins and ask him to choose a more secure password. Next, I sent the list to management and asked for permission to contact the vice president of IT at one of our subsidiaries in order to gain his support for instituting a stricter password policy.
Overcoming password hell
The next steps are to put together a stricter password policy, obtain buy-in from management, publish the new policy, change the technical password management policy to the stricter settings - and wait for the outcry from end users. Adopting a stricter policy sounds like a logical idea, but as we security professionals know, what makes perfect sense to us often comes up against all kinds of resistance.
An interesting question, though, is what our new password policy will look like. One of my security engineers is hellbent on implementing OTP (one-time passwords) via SecureID tokens. We already have a token authentication scheme for remote users logging in via VPN, but tokens aren't currently used internally. I keep telling him that this approach won't ease the password hell facing our internal end users. Many of them, needing multiple passwords to log onto myriad applications, just tape their passwords to their monitors. I expect that's what will happen with the tokens as well. Or worse, users will lose their tokens every other day. I suggested that we sponsor a single-sign-on project instead.
An interesting option is to use passphrases instead of passwords. Think about it: The longer the password, the harder it is to crack. A passphrase like "All I want for Christmas is my two front teeth!" is statistically more difficult to crack just by virtue of the number of characters, the addition of spaces, differing word lengths and placement of the words. As I looked into this issue, I came across a recently published series of articles by Jesper M. Johansson , who is the security program manager in Microsoft's security business and technology unit. What a timely find!
Johansson's three-part series explores the question of whether passphrases are better than passwords. Part 1 gives the fundamentals about using passphrases, Part 2 focuses on the mathematical statistics behind cracking passwords and passphrases, and Part 3 gives guidance on how to choose passwords and configure a password policy.
In Part 2, Johansson claims that users can remember long passphrases, that longer is stronger and that passphrases can have more randomness than passwords.
I'm fascinated by the passphrase-vs.-password debate, and I'm eager to see how it turns out. At my company, we've been trying to train end users to add special characters to their passwords and to create (and remember) nonsensical passwords. Wouldn't it be grand if we could show them an easier way that was much more secure?
This week's journal was written by a real security manager, "C.J. Kelly," whose name and employer have been disguised for obvious reasons. Contact her at [email protected]