It’s widely regarded that passwords should be changed regularly. The Australian government declared last week the “National Cyber Security Awareness Week” [1] and has published a list of tips for online security which includes “Get a stronger password and change it at least twice a year“.
Table of Contents
Can a Password be Semi-Public?
Generally I think of a password as being either secret or broken. If a password is known to someone other than the sysadmin and the user who is authorised to use the account in question then you have potentially already lost all your secret data. If a password is disclosed to an unauthorised person on one occasion then merely changing the password is not going to do any good unless the root cause is addressed, otherwise another anothorised person will probably get the password at some future time.
Hitachi has published a good document covering many issues related to password management [2]. I think it does a reasonable job of making sysadmins aware of some of the issues but there are some things I disagree with. I think it should be used as a list of issues to consider rather than a list of answers. The Hitachi document lists a number of ways that passwords may be compromised and suggests changing them every 60 to 90 days to limit the use of stolen passwords. This seems to imply that a password is something that’s value slowly degrades over time as it’s increasingly exposed.
I think that the right thing to do is to change a password if you suspect that it has been compromised. There’s not much benefit in having a password if it’s going to be known by unauthorised people for 89 days before being changed!
Fundamentally a password is something that can have it’s value rapidly drop to zero without warning. It doesn’t wear out.
Why are terms such as Three Months used for Maximum Password Ages?
The Hitachi document gives some calculations on the probability of a brute-force attack succeeding against a random password with 90 days of attacking at a rate of 100 attempts per second [2]. I think that if a service is run by someone who wouldn’t notice the load of 100 attempts per second then you have bigger security problems than the possibility of passwords being subject to brute-force attacks. Also it’s not uncommon to have policies to lock accounts after as few as three failed login attempts.
Rumor has it that in the early days of computing when the hashed password data was world readable someone calculated that more than 3 months of CPU time on a big computer would be needed to obtain a password by brute-force. But since then the power of individual CPUs has increased dramatically, computers have become cheap enough that anyone can easily gain legal access to dozens of systems and illegal access to a million systems, and it has become a design feature in every OS that hashed passwords are not readable by general users. So the limiting factor is to what degree the server restricts the frequency of password guesses.
I don’t think that specifying the minimum password length and maximum password age based on the fraction of the key space that could be subject to a brute-force attack makes sense.
I don’t think that any attempt to make an industry-wide standard for the frequency of password changes (as the government is trying to do) makes sense.
Can there be a Delay between a Password being Compromised and being Used by an Attacker?
Hypothetically speaking, if a password was likely to be compromised (EG by having the paper it was written on lost or stored insecurely) for some time before an attacker exploited it, then if the password was changed during that time period it could solve the problem. For example when a company moves office there is the possibility of notepaper with passwords to be lost. So if the sysadmin caused every user password to expire at the time of the move then a hostile party would be unable to gain access.
Another possibility is the theft of backup tapes that contain the list of unencrypted passwords. If users change their passwords every three months then the theft of some four month old backup tapes will be less of a problem.
Another possibility concerns the resale of old computers, phones, and other devices that may contain passwords. A reasonably intelligent user won’t sell their old hardware as soon as the replacement device arrives, they will want to use the new device for some time to ensure that it works correctly. If passwords expire during this trial period with the new device then passwords stored in the old device won’t have any value. The down-side to this idea is that people probably sell their old gear fairly quickly and making passwords expire every two weeks would not be accepted well by the users.
It seems to me that having bulk password changes (all passwords for one user or for one company) based on circumstances that lead to potential insecurity would do more good than changing passwords at a fixed schedule.
How are Passwords typically Compromised?
Dinei Florêncio and Cormac Herley of Microsoft Research and Baris Coskun of Brooklyn Polytechnic University wrote a paper titled “Do Strong Web Passwords Accomplish Anything?” [3] which discusses this issue. The first thing that they note is that nowadays passwords are most commonly compromised by phishing and keylogging. In those cases passwords are typically used shortly after they are stolen and the strength of a password never does any good. That paper suggests that banks should use stronger user-names rather than stronger passwords to combat the threat of bulk brute-force attacks.
Can a Password Last Forever?
If a password is entered in a secure manner, authenticated by a secure server, and all network links are encrypted or physically protected then there should never be a need to change it.
Of course nothing is perfectly secure, so for some things with minimal short-term value or which can be used without anyone noticing there is a benefit in changing the password. But in the case of Internet banking if a hostile party gets your login details then you will probably know about it in a few days when the bank calls you about the unusual transactions from foreign countries – long before a 90 day password change schedule would have done any good.
Maybe one of the issues determining whether a password should be changed regularly is whether an attacker could use long-term read-only access to gain some benefit. Being able to read all the email someone received for a year could be a significant benefit if that person was a public figure, and there’s usually no way for an ISP customer to know that someone else is downloading all their mail via POP or IMAP.
Should a Password be the only Authentication Method?
It is generally agreed that an authenitcation method should ideally involve something you have plus something you know. That means a password and a physical device such as a smart card, token with a changing sequential password, or a key such as a Yubikey [4]. If the physical device can’t be cloned (through some combination of technical difficulty and physical access control) then it significantly improves security. When a physical device is used the purpose of the password is merely to stop someone who steals the physical device from being immediately exploit everything – the password only has to be strong enough to keep the accounts secure until a new token can be issued.
The combination of something you have and something you know is very strong. Having a physical token stored on the desk next to the PC that is used for logging in provides a significant benefit, then an attacker needs to break in to the house and can’t sniff the password by compromising the PC remotely.
Conclusion
In all aspects of security you need to consider what threats you face. If an attacker is likely to launch an immediate noisy attack (such as transferring the maximum funds out of an Internet banking account) then changing the password regularly won’t do any good. If a subtle long-term attack is expected then changing the password can do a lot of good – but a physical token is the ideal if the account is valuable enough.
But to put things in to perspective, it’s technically possible to use a mobile phone camera at close range (or a SLR with a big lens at long range) to take a photo of keys that allow reproducing them. But this hasn’t stopped people from carrying their house keys in an obvious manner that permits photography or leaving them on their desk at work. Also I’ve never heard of anyone routinely changing the door locks in case a hostile party might have got a key – although I’m sure that such practices are common in highly secure locations. Few people even take their house keys off the key-ring when they have their car serviced!
Related Posts
Defense in Depth and Sudo – when using sudo can increase security and when it can’t.
Logging Shell Commands – how to log what the sysadmin does and what benefits that provides you, it doesn’t help if the sysadmin is hostile.
Logging in as Root – should you login directly as root?
- [1] http://www.staysmartonline.gov.au/news/news_articles/feature/national_cyber_security_awareness_week
- [2] http://psynch.com/docs/password-management-best-practices.html
- [3] http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf
- [4] http://etbe.coker.com.au/2010/03/15/yubikey/
I believe email password should be change frequently.
Reason
(1) email password is easy to leak: almost all POP3 server require plain password. If you use it in untrusted network (e.g. hotel), it may be sniffed.
(2) Unlike your windows account password, the attacker cannot plant a spyware on your computer; they would keep login your account periodically. Changing the password stop this.
The big problem I have run into is that when dealing with general policies of password changing and such you have to deal with several unknowns.
1) Are you dealing with a threat that is centralized or distributed. In the case of password guessing, you tend to run into a ‘many on many’ problem where there are many places you can test authentication so a test of 100 passwords per minute is lost in the noise of everything else. Most bruteforce tools are distributed to deal with things like denyhosts so you can watch a dictionary search occur from many ip addresses with various ones starting up where others stopped.
2) The next issue is that a password does not have a known expiration anymore than you can tell when a single atom of U-239 is going to decay. You just know that at some point its not going to be good anymore. However I ‘feel’ (I do not have definitive data to prove this) that groups of passwords do have a decay pattern. Having done various brute force audits of passwords I was amazed about how many passwords were either duplicates or near duplicates even when dealing with multicase rules. People use common events (911, 42, etc) names etc that on a large scale a password guessed at one spot is probably going to show up a lot. [The making of usernames to be harder is probably a good idea but limited in that at some point they will be public somewhere.]
3) The risk of a guessed password in an enviroment where guessing is ‘free’ to the criminal means that while it is slow it is no less valuable than getting passwords from a keylogger. Heck do both.. get a known good password and see how many other people use it (or a variant) elsewhere to walk the system.
With these risks, changing a password regularly looks to be a control that still has merit. What needs to be ‘proved’ is that it makes security worse overall before it becomes a not recommended practice.
> Generally I think of a password as being either secret or broken.
You are right in the sense that a password is either known to
others — or not. However, given that secrets do leak, it is not
unreasonable to try to estimate the waiting time before there is a
high likelihood of the password having leaked.
As the previous commentor has said, there are a number of services
that one might have to use which are not secured as well as one might
want. Now a compromise is not likely (i.e. probability less than 50%)
to occur _every_ time one uses the service. Through repeated use,
the likelihood that, at least one of those times, there was someone
“listening in”, increases.
Even with services that one considers secure, vulnerabilities are
often found over a period of time. So one must again estimate the
waiting time for a vulnerability to be found and change one’s secret
_assuming_ that one has been found (whether a vulnerability has been
published or not). Over a period of time, as the service acquires
greater trust this waiting time would increase.
You are completely right that these estimates are better
characterised as “guestimates”, but that is the nature of the game!
The one reason to change them often is hidden behind your statement “if you suspect [it] has been compromised”.
I can think of quite a few scenarios where you have no reason to suspect so, but it could have been.
What a password-change does then is damage control. (Which is somewhat defeated by the fact that if this change period is *mandated*, people end up using easy ones anyway… )