How does changing your password every 90 days increase security?
Where I work I'm forced to change my password every 90 days. This security measure has been in place in many organizations for as long as I can remember. Is there a specific security vulnerability or attack that this is designed to counter, or are we just following the procedure because "it's the way it has always been done"?
It seems like changing my password would only make me more secure if someone is already in my account.
@Bill, thanks for this great question! We love rocking the boat and questioning "accepted wisdom"...
It certainly makes sure that half the office has stickies with their password on their monitor or under their keyboard.
A better question: If this is necessary, how many of those same admins are rotating their service account passwords that typically have way too many permissions? Most places I've worked set those to never expire.
I hate this rule and have argued against it a lot. http://blog.damianbrady.com.au/2008/07/02/most-password-policies-are-bad/ for more details (in a comment for 0 rep)
@johnfx, definitely. And how many allow exemptions for C-level (especially CIO) and directors (especially director of IT) who demand not to have expiring passwords.
Obviously changing the password every day is impractical. If you graph the impracticalness vs number of days, and the increase in security vs number of days on the same graph, the lines always cross at 90 days, so 90 days is optimal :)
I convinced the IT dept at my last job to make a tradeoff. We got rid of the password expiration policy in favor of stronger passwords. Everyone loved this decision, as they were able to actually remember their new password without keeping it posted to their monitor. Plus, their new passwords were more secure.
I interviewed the IT-manager at an organization, and he said when the relaxed their password policy, the yellow notes started to disappear.
Yahoo is doing away with passwords, going password free. I think this is a better idea. They text you a password that is only "good" for 5 minutes, or X amount of time, but you get to keep you authentication cookie. So it's like changing your password every time you login.
Would like to add ,Users are not careful enough with their passwords while creating accounts on other sites , So for example A has thought of a new password X for his banking transaction , in a months time he might make many more accounts on lot less secure sites ( which does not use HTTPS/SECURE HASHING/... ) where he might use the same password which makes him vulnerable to another attack vector . Making "time out" password a good strategy.
The reason password expiration policies exist, is to mitigate the problems that would occur if an attacker acquired the password hashes of your system and were to break them. These policies also help minimize some of the risk associated with losing older backups to an attacker.
For example, if an attacker were to break in and acquire your shadow password file, they could then start brute forcing the passwords without further accessing the system. Once they know your password, they can access the system and install whatever back doors they want unless you happen to have changed your password in the time between the attacker acquiring the shadow password file and when they are able to brute force the password hash. If the password hash algorithm is secure enough to hold off the attacker for 90 days, password expiration ensures that the attacker won't gain anything of further value from the shadow password file, with the exception of the already obtained list of user accounts.
While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups. Ideally, of course, everyone would be just as careful with the tape that has the backup from 6 months ago as they are with the production data. In reality, though, some older tapes inevitably get misplaced, misfiled, and otherwise lost in large organizations. Password expiration policies limit the damage that is done if an older backup is lost for the same reason that it mitigates the compromise of the password hashes from the live system. If you lose a 6 month old backup, you are encrypting the sensitive information and all the passwords have expired since the backup was taken, you probably haven't lost anything but the list of user accounts.
This is assuming a shadow password file exists. Many OS's don't have such a beast.
@david - Very true, the shadow password file is a Unix-ism. Most systems store password hashes somewhere, creating the potential for someone to acquire the hash, break the hash offline, and then use the cracked password to compromise the system.
The problem is that with modern EC/GPU setups, cracking even strong passwords can be done at ludicrous speed very cheaply. Combine the raw brute force with gigabytes of word lists, custom character sets, and pre-generated hashes that you can look up (for free or very cheap), and that 90 days is a perfectly large window for cracking passwords offline.
@Marcin - True. Brute force hash attacks have become much faster and older systems with insecure hash algorithms doing relatively few iterations are unlikely to hold up for 90 days. If you're using SHA-2 and doing thousands of iterations, on the other hand, your hashes should be strong enough to hold up for 90 days.
@Marcin: are you still using MD5 for hashing your password? If so, then you have a different problem.
If you're assuming that a backup has leaked and the attacker has read access to the complete filesystem, ssh private keyfiles should be a much bigger concern than shadow passwords.
So, in other words, it tries to prevent a hypothetical attack (which, if it happens, means you've got bigger problems to solve anyway), but opens up a host of actual, severe vulnerabilities (Need a password? Just pick one, they're plastered all over the place. Oh, and they're leaving the company in the trashcans, too. Not valid, you say? Well, this guy had password letmein22011 for the second quarter of 2011, wonder what his password is now...). Not a very good tradeoff IMNSHO.
But... if you can get the backup, then you often don't need the passwords! You need the passwords for an up-to-date view of the content of the computer, but for many means, the older version is sufficient!
Of course the 6 month backup is next to useless if noone can remember the password they used 6 months ago - or was it the password from 8 months ago...
@JustinCave http://ob-security.info/files/oclhc-lite.avi take a look at this, does 15 BILLION per second of SHA1 sound slow to you? MD5 is 45B/sec so SHA1 not that much slower either. The point is that we really have to rethink our 'what is an average attacker capable of' approach. In 90 days this setup (single computer, 8 beefy video cards, so not cheap, but not out of range of a single person), it can crack 1.2*10^18 SHA1 combos. That's almost all of all upper, lower, and digits up 10 char passwords.
@marcin You seem to misunderstand what @Justin is saying. Anyone who is using non-iterated password hashing algorithms is over 30 years out-of-date. Unix did 25 iterations even back in 1978. Good algorithms use e.g. 10000 iterations these days, and try to prevent the user from choosing passwords that are easy to crack. See How to securely hash passwords? - IT Security - Stack Exchange
I think that a more plausible attack is not "someone acquired the shadow file and reversed the hashes", but "someone acquired the note from the CEO's trash and read his login credential". If the CEO will not change his password, the garbage man could log in a year after he found the note.
@nealmcb: That just means you raised the cost or time of the attack. 10k iterations means a linear increase in cost/time. With elastic clouds it costs the same (approx) to use 1k systems and run them in less time. Not cheap with 10k, but it depends on the dollar value of the data.
100,000? sha-1 is ~7.5 million iterations a second on a single GPU, 100,000 or less seems a little low.
@ewanm89: actually SHA-1 is even faster than that. On a somewhat old GPU (Nvidia 9800 GTX+, bought for about 100$ two years ago), I can do 160 millions SHA-1 per second. Even a 2.4 GHz Core2 quad can do 48 millions SHA-1 per second (using SSE2 instructions).
@Thomas Pornin: I should rerun my benchmarks on my GTX-265 and 2.67 GHz Core2Quad then.
`While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups.` . . . this is why *competent admins* ***ENCRYPT THEIR BACKUPS***. (It saddens me that I'm the first person to leave this comment in the 18 months since this answer was posted)
The "90 days" is a sign that this policy was dreamed-up by a security "fan" rather than a security professional. Why N days? Is there any empirical reason for it? Has anyone implementing one of these policies actually researched what the value of N should be in order to be effective? Nope.
Please see comments by Kobi and Jan28 below. If you take into account research such as The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis, then we see practically no value from password expiry policies. I have yet to see anyone who argues for password reset policies acknowledge this research.
@TheGreatContini Right on. +1 to your comment, -1 to this answer. There's a lot of conjecture here: "organizations as a whole tend to be more lax about backups" ... are you kidding me!? Do you work with a bunch of incompetents? Getting access to backups is like getting access to the computer itself! Corporate data is in there! Of course organizations protect their backups. At least, mine do! ... Just one example of a fallacy presented by this answer. -Infinity, if I could.
I have argued before that it doesn't improve anything. From that post:
Obviously the attacker does not know your password a priori, or the attack wouldn’t be brute-force; so the guess is independent of your password. You don’t know what the attacker has, hasn’t, or will next test—all you know is that the attacker will exhaust all possible guesses given enough time. So your password is independent of the guess distribution.
Your password, and the attacker’s guess at your password, are independent. The probability that the attacker’s next guess is correct is the same even if you change your password first. Password expiration policies cannot possibly mitigate brute-force attacks.
So why do we enforce password expiration policies? Actually, that’s a very good question. Let’s say an attacker does gain your password.
The window of opportunity to exploit this condition depends on the time for which the password is valid, right? Wrong: as soon as the attacker gains the password, he can install a back door, create another account or take other steps to ensure continued access. Changing the password post facto will defeat an attacker who isn’t thinking straight, but ultimately a more comprehensive response should be initiated.
So password expiration policies annoy our users, and don’t help anyone.
I would agree with this except in the instances of non-admin users. Most people probably don't have the authority to create back door accounts etc. When gaining access to a system my goal may not to try and take it over, but to gain access and steal information. As long as I have the account password, I can have access, but I don't want to do anything that might look suspicious (like creating an account). As long as the user doesn't change the password, I don't have to try and hack the account again. Changing the password to something non-predictable causes extra work for me.
This is plain wrong. We know that the attacker might have a hash of your password (Which is the reason for this policy in the first place)--which essentially gives him your password given enough time, regardless of the method he uses to crack it with. Replacing your password will thus invalidate the information the attacker has. The answer above sums it up.
And by the way, direct brute force attacks are fought by time-limiting authentication attemps and captchas, not this policy.
Most users increment a number at the end of their password. I've worked in a bank and a common password was the name of the city followed by the number of the current month. Also, since most systems are inherently insecure, especially in a Microsoft Windows environment, it does not really matter if the user is limited or not, and it most likely is not that limited anyway.
@Wolf - The bank you worked in should have a better password reuse policy which requires the new password to differ from the old by more than a character or two. And it should have been comparing passwords to a dictionary so people didn't use proper nouns / words.
@Kevin: how about a Unix system. You get into a user's account, and edit .profile to include "alias passwd=$HOME/.tmp/passwd" or just prepend $HOME/.tmp to the $PATH where the passwd under .tmp is a shell script which emails the password to my throw-away hotmail account and runs the system password command? No elevated privileges required, but there's now a simple back-door in place which keeps the account compromised.
@Sheeo direct brute force attacks cannot be fought with CAPTCHAs - "time limiting authentication attempts" (i.e. throttling and lockout policies) only can do the job.
To comments that it's to protect against offline brute force attacks against your password hashes: your directory server is probably more valuable than that. I'd try to help my users by putting in exfiltration detection on that system.
@Kevin: "install a back door" doesn't mean creating an account. Adding a line to `~/.ssh/authorized_keys` might be enough.
@dannysauer: Password reuse can prevent reusing the exact same password. It can't detect "differ by only a character or two", assuming any secure hash function. You don't think the passwords are stored in plaintext so you can compare them to the new one, do you?
@AviD♦ Uhh. How so? CAPTCHAs are designed to not allow automatized input, so if the captcha is good enough, it'll certainly fend off a direct brute force attack.
@Sheeo we're really starting to get offtopic here, CAPTCHAs are a big topic by itself. There are already some questions here discussing this... But my claim, in short - CAPTCHA solves the wrong problem, badly.
@graham For the most part I agree that simply forcing a change of password every 90 days does little if anything to improve security. However if this is complemented by a good algaritham to force a unique password each change (IE no incrementing reordering) it can help reduce your companies vulnribility to access from comprimised passwords on other sites. Though I have only worked at one place that had anything like this type of policy.
@BenVoigt During a password change, you typically prompt for both the old and new password. So, you have both available, and can check for similarity.
@BenVoigt You can make permutations of the new plaintext password, hash them, and compare the hash to the old password hash. It's not very fast or efficient if you're checking more than, say, 10 or so permutations. But for small sets, it could work. For example, if the new password is "portland11", you could hash and compare "portland10" to see if they're incrementing the number on the previous password.
This answer is BS. Password expiration DOES help against offline bruteforce attacks. Ofcourse it doesn't against online bruteforce attacks (since there the probability is indeed the same) however there are other counter measures at that level (e.g. account lockout after 10 wrong login attempts).
In regards to this: "The probability that the attacker’s next guess is correct is the same..." attackers can create more sophisticated algorithms to guess the next password within a short amount of time. A UNC study found that an attacker who used such an algorithm to learn a previous password could guess the current password in 41% of accounts within 3 seconds per account. So, I guess the probability is the same, but a more reasonable statement would be, "It depends..." https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes
@Stef Heylen I am curious if forced changing passwords regularly leads to the use of weaker passwords. It could mean that bruteforce attacks online and offline are easier with changing passwords. e.g. if the bruteforce window changed from 10 years to 30 days (which although unlikely a small reduction in complexity will lead to a parabolic drop in time to crack). Then changing passwords COULD reduce security. I suspect that any reduction IF there is one does not have a large enough effect to reduce security, but I would be curious to see if this has been studied (difficult to get data...).
Before answering whether it does help or it does not help, it makes sense to look at specific scenarios. (That's often a good idea when dealing with security measurements.)
In what situations does a forced-password-change mitigate impact?
The attacker knows the password of a user but has no backdoor. He does not want to be discovered, so he does not change the password himself.
Let's see if this scenario is likely:
How might he have learned the password?
- The victim might have told him (e. g. a new intern who should start working before he gets his own account setup, another person who should level an account in an online game
- The attacker might have watched the keyboard
- The attacker might have had access to another password database in which the user used the same password
- A one time only login using a computer owned (prepared) by an attacker.
What might have prevented him from setting up a backdoor?
- The service in question may not provide a way for backdoors, for example an email inbox or common web applications
- The privileges of the user may not have sufficient permission to install a backdoor
- The attacker might miss the required knowledge (in the online game Stendhal most "hacks" are done by angry siblings who just want to destroy some toy)
- The attacker might not have turned evil yet. (e. g. an employee that will be fired next month but does not suspect anything at the moment).
Why not use forced password expire?
It can be very annoying to users causing them to just add a counter at the end. This might decrease the entropy of passwords. According to my experience it generates additional support costs because people forget their new password more often than usual. I guess that is caused by the change password prompt catching them off guard while they are busy thinking about something else.
It is far from a cure-all and it has a negative impact on usability, but it does make sense to balance that against the likelihood and impact of scenarios similar to the one I described above.
See, now what you've done is, I'd already voted up other answers, but your answer is *more* right, so I'm bothered that I can't upvote yours twice :).
Btw, another possible scenario for finding your password, is if the attacker gained access to the database. E.g. password hashes (e.g. /etc/passwd) which may be cracked at some point... Or, for the case of common web apps, maybe the passwords are even stored in plaintext.
+1 for "The attacker might have had access to another password database in which the user used the same password". This is a very real danger. If I can hack an insecure site and discover your password there, then I can access any other systems where you used the same password. Jeff Atwood has even had this happen to him before: http://www.codinghorror.com/blog/2009/05/i-just-logged-in-as-you-how-it-happened.html . Forcing password changes may lower the chances of this happening.
Why not use password expiry? See The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis. Bottom line: it adds almost no value, yet is a burden to users.
@JoshuaCarmody - "Forcing password changes may lower the chances of this happening." How can you make that statement? What empirical evidence do you have for that? The fact that Jeff Atwood had this problem merely means that he used the same password everywhere. I use all kinds of passwords online, and I don't have a 90 day rotation period, thank God. I make sure that they're 1. Reasonably complicated and 2. Different from site to site. By enforcing a 90 day policy, you ensure 1. Simple passwords that 2.share the same base with a small rotatable portion.
There was a study by Microsoft concluding the password expiration policy does not increase the security in real life scenarios.
These articles were removed, but available on the Internet Archive:
it should be noted, that the research paper is about web-site passwords. I think this implies that the victim is the user himself or herself. In a cooperate environment the company may suffer from an attacker instead of the individual user.
Furthermore "Rule 6 [change passwords often] will help only if the attacker waits weeks before exploiting the password" is wrong. It ignores the possibility that an attack may be ongoing for weeks without being noticed. Think of an attacker having access to the email account of someone from upper management. It is obvious that the benefit for the attacker may be larger if he keeps reading potential confidential emails instead of abusing the email account for SPAM or locking the owner out by changing the password.
Kobi is right, but one more link is the final piece of the puzzle: The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis. This shows that once an attacker has one password by the user, he can quite likely obtain another. Therefore, password expiry policies are far more burden than their value.
The UK Communications-Electronics Security Group also advises against password expiration policies: https://www.cesg.gov.uk/articles/problems-forcing-regular-password-expiry
We all have our opinions, but we should also be looking for actual research on the question. Besides the paper by Cormac Herley of Microsoft on website passwords noted in Suma's answer, there is a paper from ACM CCS 2010: "The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis" (pdf), written by Yinqian Zhang, Fabian Monrose and Michael Reiter. They analyzed a great dataset and did some good analysis on how effective password expiration policies really are. Their conclusion? Forcing users to change their password every six months isn't very useful:
at least 41% of passwords can be broken offline from previous passwords for the same accounts in a matter of seconds, and five online password guesses in expectation suffices to break 17% of accounts.
....our evidence suggests it may be appropriate to do away with password expiration altogether, perhaps as a concession while requiring users to invest the effort to select a significantly stronger password than they would otherwise (e.g., a much longer passphrase). ....
In the longer term, we believe our study supports the conclusion that simple password-based authentication should be abandoned outright
For research on how to help users choose stronger passwords, see Recommended policy on password complexity - IT Security
That is the same result that I got after talking to some security auditing people about the sense of ISO 270001 - especially the password-change policy. It was their opinion that frequent password changes force bad passwords. Whereas a good password does not have to be changed that frequently.
The only two good reasons I have heard:
Window of opportunity - in an on-line attack scenario say you lockout the account for 30 minutes after 10 incorrect attempts (the Microsoft recommended setting for high security environments). Without any password expiry there is potentially an unlimited time window to attempt dictionary, brute-force, common passwords attack methods. Password expiry caps that. In an off-line scenario, where you do not realize your passwords have been stolen, again expiring passwords provides the attacker limited window of time to crack the passwords before they become useless. Of course as @graham-lee states you need other controls in place to detect things like a back-door
Compliance - virtually every regulator and auditor will look for password expiry. Including PCI-DSS, HIPAA, SOX, Basel II, etc. Correctly or incorrectly this is the world we live in. In addition the "no one got fired for buying IBM theory". If you do not have password expiry and others in your industry do, if you get hacked, then you were not following "industry standard practices". More importantly senior management cannot say this to the press, to a regulator, to a court. Same reason for having state-full inspection firewalls, anti-virus, IDS even though they are less effective now than 10 years ago.
That said as everyone has said password change is terrible for user experience, especially where there is no or limited single sign-on it can lead to "password change day" where a user goes through and changes the password for their 30 systems to the same one usually by incrementing a digit. This is clearly not desired behavior. My recommendation for changing this culture if it is possible in your regulatory / audit environment is to change your policy to remove password expiry with a clear justification (plenty here). Get this approved by the appropriate security governance and reviewed by audit / regulator. Then go ahead and change the systems. Alternatively use more single sign-on and federated ID, ideally with two factor, so that at least users only need to change one or a few passwords.
"Compliance" includes "compliance with regulations which will cause industry regulators to fine your company substantial money for incomplainace". IIRC, password rotation is a mandatory part of PCI compliance, among others.
Alas, "compliance" essentially means "clueless cargo-cult monkeys armed with checklists" these days. It is unfortunate that noncompliance will have other impacts, but that's irrelevant to security.
@Rakkhi: Yes, yes, I'm not saying it's irrelevant to everything, it's definitely relevant to the bottom line - but so is everything else a company does. It's security theatre, not actual security (not sure if that's within the scope of this question though).
@piskvor only in scope so far as there are things you have to do for the bottom line and to comply with regulation that you may not really think increases security (or worse decreases it). Doesn't change the fact you still have to do it. What you consider security theater has a multi-billion dollar business built on it.
@Rakkhi: Of course it is a multi-billion dollar business; selling snake oil and miracle cure-alls has been profitable throughout human history. Profitability != utility.
HIPAA at least does not require password expiration. It requires "Password management (Addressable). Procedures for creating, changing, and safeguarding passwords." https://www.law.cornell.edu/cfr/text/45/164.308 (a.5.ii.D)
Your paragraph about compliance is very very useful. I also agree with you and @Piskvor that it's basically security theatre designed to charge a lot of money for simply checking a few boxes. However it's an extremely relevant factor without which you can not discuss the issue itself. Thanks for adding it ;)
One reason not mentioned here, is that it prevents people who use the same password for everything from getting your system compromised if their password is figured out somewhere else. After a few passwords expire, users will start to have to come up with original passwords, which means when their favourite password is stolen and all their emails, social networking sites, and personal accounts get hacked, your system will still be secure.
`users will start to have to come up with original passwords`. This sounds like wishful thinking to me. Most users are likely to 'game' the system using sequentially increasing suffixes or similar, or pingponging between two passwords. (Please don't suggest that you store every password that the user has ever used...)
@Roddy: I've used one system that stored my last ten passwords, but unfortunately it *was* possible to use sequential suffixes.
How does forcing you to change you password on system A prevent you from changing the password on system B to match the new password on system A? Now the user changes their password on both systems every 90 days but the passwords stay in sync.
@alain this ignores password change day where people change all their passwords to the same new one.
Most sites don't require you to change your password. No one is going to change their hotmail, gmail, facebook, myspace, etc. passwords just to match their work computer password. The password reuse is a result of laziness, and that same laziness is why after the first few changes, there's a high chance the password is one they uniquely use for that system.
As for the reuse of previous passwords - most systems allow minor variations (change suffixes or prefixes), but few systems that force a password change allow reuse of the last 10 or so passwords. (As Bill mentioned). Even then, these same systems often have other security measures, such as a lockout if more than 10 unsuccessful attempts are made. With the number of possible permutations that can be made to a known password to make it only slightly different, there's still a good chance of stopping a brute-forcer with the user's common password.
I worked at a place that actually had a good algarythim that would not allow for a password that contained more 50% or more of the same characters from my previous password or that shared more than 33% of similar sequential characters to any of the last 12 passwords. So if you have a 9 character password you can reuse only 3 characters togther as part of your password. if it is 8 then only 2. It also required a special char a number and a upper and lowercase letter with min length of 8. I think there may have been a few other rules too but it was just easier to use a random than reuse.
Haha, I think if my company were that strict, it would be a formula for 1: Never logging out, 2: Everyone having a convenient sticky with their current password stuck to their monitor. Super Secure!
@Chad: That's not a "good algorithm", that's a security vulnerability. In order to enforce those checks, the passwords must be stored using reversible encryption (if they're even encrypted at all). No one who understands security stores passwords in a way that allows recovery of the plaintext, or even a list of characters in the password.
@Ben Voigt: you don't need to use encryption, a single way hashing of old passwords and then iterating the new password over few simple algorithms (find a number -- increase it, find a word -- reverse it) by computing few hundred such combinations and comparing with used hashes will make it impossible to reuse passwords while not storing the passwords in clear or in reversible encryption.
@Hubert: By generating variations from the new proposed password, you do indeed remove the requirement to get the old password back in plaintext. But at the same time, generating and hashing variations is very wasteful, it's nearly as hard as a brute-force attack on the password. The guiding principle of security is to make the bad guy solve a problem much harder than the one facing the good guy. When you give the good guy the same problem...
@Ben Voigt: It's only to check if the password is not a minor variation on already used one. Yes it does make changing passwords more labor intensive, but generating even 1000 password variations with 10000 round PBKDF2 will take less than a second on any desktop computer, with NTLMv2 hashes you can try 1000000 variations for no visible drop in performance.
@Hubert: If you're trying so few variations that they can be tested in under a second, you aren't raising the bar for an attacker enough to be worthwhile. Also, wouldn't you agree that the level of reuse Chad said was forbidden would require having plaintext of both new and old? To determine whether three characters out of 9 are reused, you need to try those 3 in all possible positions, and try every possible character in every other position! The method of generating variations and computing and comparing hashes is prohibitively expensive, very nearly as hard as bruteforcing from scratch.
@Ben Voigt: I'm rising the bar for the user to think sufficiently different password from any already used, if anything I'm *rising* the bar for attacker that knows at least one previous password (from a stolen smartphone or laptop's wifi configuration) and leave it at the same level for other attacks. It will stop users from using "pa55w0rd022011", "pa55w0rd032011", etc. it won't stop them from using "abba73alpha", "abba73beta", etc. I say it's a win
@Hubert: Well, Chad's comment that I replied to claimed it would prevent "abba73alpha" from being followed by "zyxw14alpha". Nevertheless, if you're raising the bar for an attacker to "more than T time", it's only by spending "T time" on each password change attempt. Any time your work is comparable to the attacker's task, it's a bad design.
@Ben Voigt: It still increases the amount of work like O(log(n)) where n is number of past passwords. I just don't see where it is comparable to attackers task, I just perform those 1000 or so password hash computations, it's more akin to using slower CPU, not easier to crack algorithm. It's protection from leaked plain text passwords. By preventing simple modification of passwords we secure our network against online brute-force (which speed can be easily throttled).
Even us security guys game the system and use iteratively increasing digits tacked on the end.
I'm giving this a +1 for being out of the box enough (controversial even?) that it made me think of another scenario/reason for regular password changes - evolution of log-in security itself. When you'd design new validation methods, chances are you'd want to invalidate all previous user passwords anyway. Having users change their passwords at regular intervals presents an opportunity to implement these changes without causing additional headaches, only keeping two latest validation methods active, and even then for only up to a preset time period.
@BenVoigt I realise this is a really old thread, but since no one else seems to have mentioned it, and someone else might also read this thread with interest: Password change screens often require putting in your old password. So you'd have it to compare it with the new one right at the moment of submission; you don't need to persist it, just check that it's correct, then hold it in memory long enough to compare the new password to it. (That's not to say I like this approach - just that it doesn't necessarily imply you need to persist the password with reversible encryption or as plaintext.)
@pinkgothic: That helps you with the valid-but-expiring password, but the comment I was replying to talked about variations on the past 12 passwords How do you get the other 11? Require the user to enter them all when changing his password?
How much will an expiration of passwords improve security?
This image shows, for some scenarios, the relation between time and the probability, that a brute force attack on a type of password succeeded, depending on the regular change of the password. The absolute timespan is of minor interest. How long it is - either there is not much difference, or the vulnerability is already pretty high.
As mentioned from others before, there are different scenarios, where changing the password might help:
- a) User A tells a coworker B his password in a special situation. Later B is fired. He now might think about misusing the password of A (his own account is deleted, we assume), but it could need some time (losing a dispute against the company in court, for example) before starting his attack. Here, it is very useful, to change the password - but of course not from secret2010 to secret2011.
- b) Attacker has access to the shadow file, and is brute forcing with certain amount of CPU-power (or GPU).
In the case b), the policy to change the password, looks reasonable, but you do only profit, if the risk to be vulnerable is already really high. Let me explain it with numbers:
Assume an attacker might try 250 000 passwords per second. Assume you say the password expires after 183 days, (about 6 months). The password is generated from a-zA-Z0-9 which is 62 signs. Assume the password is 8 signs long. Check how probable is a breakin after 10 year, which is 20 change intervals.
I've written a program, to test different parameters; call the program with
java PasswordCrackProb 8 62 250000 s 183 20 len = 8 signs = 62 attacks per day = 21 600 000 000 change after days= 183 intervals = 20 days = 3660 years = 10 M = 218 340 105 584 896 attacks = 79 056 000 000 000 p(cracked) = 0,3620773 without change p(cracked) = 0,3060774 with change
The result means, that it is cracked with 36% chance if the password wasn't changed, and with 31% if it was changed (but the attacker has a fresh shadow file). The difference is significant, and more so, if we take a longer time, 40 intervals, like 20 years:
p(cracked) = 0,7241546 without change p(cracked) = 0,5184715 with change
but while 52% is much lower than 72%, 52% might not be acceptable.
But if we look at smaller intervals, the relative difference between changed and unchanged passwords gets smaller and smaller.
p(cracked) = 0,0905193 without change p(cracked) = 0,0873006 with change
If you assume more CPU power or weaker passwords, the crack time gets smaller, of course, but the number of attacks per day is not very interesting. We have to assume: We can not enforce the user to change the password on a daily basis. So some days - maybe a week - is the minimum. And we don't need a maximum for longer than 20 years. Systems change, people change jobs. You cannot avoid to change the password after 20 years.
If the attacker has too much power, and brute forces the whole namespace in a single day, a weekly change won't help you much - he always wins. And if the attacker can only brute force 1% of the namespace (for a given password length) in 50 years, it doesn't help as well, to change the password - you will (nearly) always win.
Only in an intermediate, balanced scenario, the password change could make a difference, but do you really know, whether the bad guy needs 1, 10 or 100 years to brute force your password?
But keep in mind: If the attacker only once had access to your shadow file, which is now expired, the comparison from my program doesn't fit.
I like this answer, however I am amused that your graph goes up to 120% likelihood :-)
A dot on the frame can easily be overseen. Since there is no dot on the 120% level, there is nothing directly wrong with it, and OpenOffice displayed the 120% by default. Using the graph without further graphic manipulation was just a fast solution.
LOL - it was purely the labelling that amused me. I think the graph does a good job of providing visual indications of that increasing gap over time.
Yes, but only worth mentioning, when the `insecurity` is already at about 40% or higher.
Very interesting. Note that the curves are almost the same in the lower part of the plot - where you should hope to be.
Simple answer - these days it almost never helps. Previous answers give the main two scenarios where it will, but even then, 90 days is still not that useful.
It could be worse - we spent ages persuading people that 30 days was too short but back in the day when stealing the SAM was relatively easy folks were very worried about a brute force attack on the SAM. We got many companies to agree on a compromise of 90 days but although cracking power has definitely gone up, hashes are better protected and generally most places now have at least some password complexity rules in place so it has become far less important.
alsop has your thinking on this been affected all by the large number of recent breeches? e.g MTGOX whole database being dumped. I have definitely upped my likelihood rating on off-line password crack in my attack trees. Even with basic complexity amazing how many set Password1 etc
@Rakkhi - I tend to rely on the wondrous powers of longer passphrases:-) I do agree though that the database dumps are an issue for those who use simple/short passwords.
alsop don't know any organization that sets a 12 char or 14 char min password length though
I would just like to add one thing. We can approach to this problem from social angle. By reseting password every X days we are telling the user - Hey, this is important and it should not be taken lightly!
This is actually a very important point, that is often overlooked. The problem is finding the balance between "changing passwords very 30 days is plain STOOPID, lets just post our passwords everywhere", and "hrmm, password? Yeah, I think I got one of those thingies a few years ago, when I joined the company... it's probably written on my employment form...". Intuitively, I would guess between 6 months to a year is often enough to remind the user of the password sensitivity, but not too often to really bug users. But yes - social aspects have a bigger impact on security than is often considered