by [Edit: This entry was posted in 2006. I no longer consider password expiration to be a useful security measure. Please see my new post on this topic here or here. I've also added some in-line comments below.]
Recently, as noted on Slashdot, Gene Spafford, author of Practical Unix and Internet Security and one of the first analyses of the Morris Worm posted an entry on his blog titled "Security Myths and Passwords."
Spafford's blog entry discusses the various vulnerabilities inherent in password based authentication and why, he thinks, password expiration is a pointless vestige of a bygone era: http://www.cerias.purdue.edu/weblogs/spaf/general/post-30/
Prof. Spafford is a widely reconigzed expert in computer security. People listen to him and this is what makes his recent post so frustrating for me. His chief claim is that password expiration, a commonly recognized "best practice," has been held over from the days of mainframe computing but really offers no benefit today. Unfortunately, he's got it wrong.
[Edit: He wasn't wrong. I was. Expiration just doesn't reduce exposure in a meaningful way and encourages people to pick weaker passwords. It also happens that most people do not pick completely new passwords so it is often easy to guess a user's new password if you know his old one. Use expiration if its the only way to make your auditors happy. Otherwise, use the best password hash that you can and educate your users.]
Gather around my pedestal for a moment, will you?
Spafford's claim revolves around a couple of key points:
1) When an account is compromised, the password should be changed now, not in a month.
2) Attackers have sufficient resources that frequent password changes, cannot, on average, negate cracking attempts.
The first point is certainly correct but, much of the time, we don't know when an account has been compromised. Changing passwords frequently narrows the window within which an account is usable to an attacker before he has to take additional steps to maintain access. If an attacker only has access to one account, changing the password removes access.
[Edit: In many/most cases, an attacker dosn't need long-term access. In those cases, expiration cannot provide a substantial benefit.]
Consider the case where a person's ex-boy/girlfriend knows their email password and is using it to snoop on them. Changing the password will, in most cases, eliminate the snooping because the ex probably doesn't have a good way to get the new password. Note that the person may not realize that the other person knew the password or that they were being spied on.
[Edit: This scenario makes some sense applied to personal accounts, but less when applied within a business. Also, with physical access they can get the new password with a keyboard sniffer or by recovering the saved password from the web browser. Again, expiration just doesn't do much.]
Password expiration also makes sense when an attacker has access to multiple accounts and uses them to access a computer system or network over an extended period of time. The attacker might gain access through a remote exploit and save a copy of the hashes so that he can get in if the vulnerability is later patched.
[Edit: The attacker would probably just install a backdoor or rootkit. He can also re-steal the hashes as often as he needs to.]
If the site has a policy in place that required passwords to expire after say, 30 days, the attacker would have to re-steal the password hashes on a regular basis to preserve his access. This behavior would have been time consuming and risky. The more often he connects, the more likely he is to be caught.
[Edit: One of my current responsibilities is supervising a help desk. A 30-day expiration is a support nightmare. I've heard of some organizations going with a 60-day expiration, but 90 days or more is probably typical. That further limits any potential effectiveness. To really limit exposure, this should be a day or less which is not practical whatsoever.]
An attacker can get around password expiration somewhat by installing backdoors but this also increases the chances that his intrusion will be discovered (especially if he's not expert enough to write his own kernel-level backdoors.)
Password expiration does not offer any benefit when an attacker wants to do all of the damage that he's going to do right now. It does offer a benefit when the attacker intends to continue accessing a system for an extended period of time. Spafford's other claim is that, with the availability of bot nets and other powerful resources, passwords simply aren't safe from cracking attempts. This claim is absolutely true, assuming that you're still using the decrepit 8-byte only, DES-25 algorithm found in older Unix crypt() implementations. If you are, you may as well use telnet too (it's WAY safer than SSH) and make sure the root password is "god" beause nobody will ever guess that. If, on the other hand, you're hashing your passwords with bcrypt (preferrably) or MD5-crypt it really doesn't matter how many bot nets, grid networks or vector computers an attacker can harness as long as you're picking good passwords (you are, aren't you!?)
[Edit: Most sites are using MD4 (Windows), MD5, or SHA-1. From what I can gather, very few websites use bcrypt, scrypt, or PBKDF2. Internally, AD and LDAP are the most popular authentication choices. These passwords can be cracked very quickly. Password expiration won't limit the damage very well unless you're willing to change passwords daily. Instead of password expiration, consider two-factor authentication.]
The bcrypt password hashing algorithm, with default settings, is about 745 times slower than the old DES-25 crypt. MD5-crypt is still too fast (it's only about 56 times slower than crypt) but you can fix that easily enough by creating your own variant of MD5-crypt that has a longer internal loop (but is otherwise unmodified). I wrote about this in ;login: in Dec. 2005.
Implementing good password complexity requirements will, obviously, help to deter offline cracking attempts. With MD5-crypt and bcrypt, long, well-chosen passwords should be safe from offline cracking attempts until after you're dead. Of course, most people don't choose great passwords even with complexity requirements in place. To aid these users, we can use password expiration. With expiration, their passwords only need to hold up for a month or two.
[Edit: Expiration policies actually encourage people to pick weaker passwords. This is not a good trade-off. If users pick passwords that are a single character shorter or that use a more limited character set, it results in a net loss of security.]
If you're using Windows, you're out of luck. The password hashing used in Windows is really, really bad. Wearing-black-socks-with-sandals-and-a-feather-boa bad. Windows passwords can usually be cracked in a few seconds whether they are well chosen or not. The situation is better if you disable LANMAN authentication and the use NT-dialect hash only (you do, don't you?) Even so, you don't actually need to crack passwords to login to Windows anyway. Even though Hobbit and Mudge and Bruce Schneier harped on NTLM authentication years ago, nobody seems to realize that you only need the hash to log on to Windows (as long as you do it remotely). So, if you get the password hashes from a Windows box, go ahead and crack them if you can. It'll save you some effort if they crack easily. If not, write your own NTLM client and logon using just the hash.
[Edit: Since you can login to Windows boxes using the hash directly, it really makes password expiration less effective. In this case, an attacker generally doesn't need to crack the passwords so it's a simple matter to just re-steal the hashes once a month to stay ahead of the curve. Or he could install a rootkit. That works too.]
I'm going to step off of my pedestal now, thanks for listening.
root as always,
Steven
[Edit: my current blog is at http://bugcharmer.blogspot.com/]