NavigationRecent Updates |
In defense of password expirationSubmitted by unicityd on Thu, 2006-04-27 15:19.
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: 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. 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. 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. 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. 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. I'll offer up a personal anecdote. When I was a teenager, I broke into other people's computer systems. I'm not proud of this but I do try to be candid. At one time, I had access to a computer network that contained a few thousand systems. I first gained access to the systems using a remotely exploitable bug. One of the first things that I did was save a copy of all of the password hashes for offline cracking. The hole that I used to gain access initially was patched not long afterward. Unfortunately for the administrators of the systems, they did not have a password expiration policy in place. If they did have a policy in place that required passwords to expire after say, 30 days, I would have had to access each domain and standalone server as an administrator every two or three weeks in order maintain my access. This behavior would have been time consuming and risky on my part. The more often I connected, the more likely that I would get caught. As it was, most of the administrative passwords hadn't been changed in about three years. This particular organization wasn't the only one that I encountered that could have better protected themselves with good password policies. 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!?) 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. If you're using Windows, you're out of luck. The password hashing used in Windows is really, really bad. 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 much 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. I'm going to step off of my pedestal now, thanks for listening. root as always, Steven *A soap box just wasn't good enough Trackback URL for this post:http://lopsa.org/trackback/295
unicityd's blog | add new comment | 9529 reads
|