Diary

 

Password rules: Change them every 25 years
Share |
Published: 2009-11-02,
Last Updated: 2009-11-02 11:31:30 UTC
by Daniel Wesemann (Version: 1)
26 comment(s)

While there certainly are parts of the password rules - like length, complex syntax, special characters, etc - that indeed may contribute to improving password security, the often stated requirement to change passwords every 90 days has far less obvious benefits.

There are four basic ways for a bad guy to get your password:
(a) Ask for it. So-called "Phishing" and "Social Engineering" attacks still work, and always will
(b) Try dictionary words at the login prompt in the hope to get lucky ("Brute Force")
(c) Obtain the encryped/hashed password somehow, and crack it
(d) Leech the password off your computer with keylogger malware

None of these four scenarios becomes less likely if you change your password every 90 days. If the bad guy can't break the password hash (c) within a couple days, he'll likely just look for an easier target. Attack (b) is also out for quick wins - either it works within the first couple dozen passwords tried, or the bad guy moves on to easier prey. If (b) or (c) are successful, or the attacker already has the password through (a) or (d), 45 days on average is more than enough to empty out your bank account or use your email address for a big spam run.

The concept of password expiry remained the same for the last 25 years or so. Infosec professionals, auditors, PCI, ISO27002, COBIT, etc all keep requiring it, unchanged, even though the threats have changed quite a bit. Forcing a user who had a weak password to change it will just make him pick another weak one. Forcing a user who had a very strong password to change it will eventually annoy the user into using simpler passwords.

So what gives? There is one practical benefit. If someone has your password, and all they want is to read your email and remain undetected, they can do so forever, unless you eventually change your sign-in secret. Thus, regularly changing the password doesn't help much against someone breaking in and making it off with your goods, but it DOES give you a chance to shake off any stalkers or snoopers you might have accessing your account. Yes, this is good. But whether this benefit alone is worth the hassle and mentioned disadvantages of forcing users to change their password every 90 days, I have my doubts.

Infosec risk management is about identifying threats and vulnerabilities, and then picking a countermeasure. But if the chosen countermeasure doesn't in fact make the identified threats less likely, all we do is play security theater, and the countermeasure is one that we don't need.

Unless, of course, "best practice standards" and audits force us to have it.

 

Keywords: password
26 comment(s)

Comments

The last line in your entry hits the problem right on the head. Unfortunately most auditors we encounter have no clue on the **why**s of what they are requiring.

What do you recommend we do in these situations?
posted by Ryan, Mon Nov 02 2009, 13:05
My thoughts exactly. Just last week I wrote an article on more or less the same topic. Hope that a day will come when the people responsible stop following "best practices" blindly.

Link to my article: http://www.gfi.com/blog/security-vs-productivity-in-the-workplace/
posted by Cliff, Mon Nov 02 2009, 13:39
I introduced the "change your password every 90 days" rule in a fortune 500 company and I will explain why. Many people use the same password on multiple systems. I discovered that one of our systems allowed users to view the password hashes in its name directory (as a "hidden" field) so I investigated the hashing algorithm it used and found that the default was the weaker of the two that shipped with the product. We quickly changed that after I verified that cracking of that hash was possible (by brute force with a modified "John the Ripper"). We then introduced the 90 day rule to ensure that there is a continual clean up of password hashes as we improve password hash security across all of our systems. It also discouraged people from using the same password on external web sites as they used on company systems.
posted by kevinm, Mon Nov 02 2009, 13:47
Mitigation of the attack doesn't change it's probability of occurrence, instead, it changes its probability of success. You've made two assumptions: 1) all password thieves will give up after a few tries in the case of brute-force attack, and 2) all thieves will give up after a few tries in the case of dictionary attacks. Maybe this is the case, generally, but not always - it depends on the specific adversary. You're implication that we (auditors) are blind to the changing threat scape is simply not always true - every 90 days is still too long given today's processing power. You have to take length, complexity, history, and the various account lockout policies into consideration when looking at password lifetime. These controls, along with the supporting audit-related controls, work in concert to provide the best possible protection for a given system.
posted by Adam, Mon Nov 02 2009, 14:03
I always considered password change interval to be related to the processor power of the day. The time it takes to crack hashes and produce rainbow tables decreases with processing power increases. Moore's law can be used in describing this effect to help understanding. I start be calculating the password space in relation to the complexity rules in effect. I then use benchmarks of cracking tools and external research to arrive at a realistic password per second cracking rate for the hash in question. Then in order to determine the number of days for changes, an acceptable percentage of password space being cracked over the time period is selected.

It's an eye opener to some that even a "strong" password can fall in seconds if it is the first generated by the password cracking tool.
posted by Scott, Mon Nov 02 2009, 14:32
I suppose dictionary attacks only work, if an account is allowed 22K attempts per minute ? (or am I missing something else ?)
posted by Mike B, Mon Nov 02 2009, 14:44
Frequent password changes do not significantly add to security unless the changes are performed more regularly than the attacks can be generated (very unlikely).

If we were regularly using robust, multi-factor authentication for the majority of our logons, we wouldn't be so focused on frequent password changes.

-ASB: http://xeesm.com/AndrewBaker
posted by ASB, Mon Nov 02 2009, 15:50
This post hits the issue on the head, and I've stepped in this minefield recently at my employer. But it's hard to win the argument without any citations.

Are there any studies to support the assertion that forced rotation actually leads to weaker passwords? Seems obvious to me, but that's just 'anecdata'. :)
posted by Zandr, Mon Nov 02 2009, 16:22
As my diary post and also various comments above state, there are certainly threats against which frequent change of the password DOES help. But the measure should always match and mitigate an identified threat, and not be applied blindly "because it is best practice". Just as you shouldn't use this diary post to blindly decide that you do NOT need a password expiration :)
posted by Daniel-ISC, Mon Nov 02 2009, 16:36
One of the reasons for frequent password changes is to compensate for weak controls on closing user accounts. Many organizations have trouble closing user accounts on all systems soon after a user is de-authorized. For example, if an organization is good at shutting down VPN accounts quickly, but bad at dropping database accounts, then in 90 days the database account will expire, but the unauthorized user won't have an easy time renewing the account.

What I can't understand is the trend to more frequent password change requirements. 10 years ago, annual password changes were sufficient on many systems. Until recently, 90 days was the standard. Now I'm seeing 60 days, and expect 30 days very soon.

I've never gotten an explanation of what vulnerabilities are present in, e.g. days 61-90 that weren't there on days 1-60. We're just forced to implement shorter password changes. I know from spot checks that shortening password change intervals drives more users to put passwords under keyboards, etc.

Crackers have broken systems which use tokens that change passwords every 5 minutes, using keyboard sniffers and real-time monitoring and exploits. We'll never get password change intervals short enough to mitigate those attacks.

We've gone past the point of diminishing returns on short password change intervals. We should focus on improving controls in other areas, and augmenting or replacing usernames/passwords for authentication.
posted by Rex, Mon Nov 02 2009, 16:54
In addition to weak controls, with any sizeable user population you have a problem with a large number of users re-using passwords. People will re-use passwords at work, on websites, at their banking institution, etc. So, all it takes is for one of these accounts to be compromised and the password goes into the database.

So, we continue to recommend better password techniques - here's a video:
http://vimeo.com/3546084

Michael Argast, Security Analyst, Sophos
posted by Michael, Mon Nov 02 2009, 17:00
Passwords are always a weak issue. No matter what you do these passwords are being created by people who are not thinking about what someone might guess. They are creating them so they can remember them, which means a decent Facebook profile may allow the intruder a simple path to guessing it.

What organizations fail to do is log failed attempts, and then act as a security team on them.

Also, limiting where you can log in from is a good approach. For instance, if your end-user has static a IP, USE IT as a requirement! If you know your users only come from one range, lock it in so 99% of the world is not in your accepted logins range and use what you know is acceptable. It is more about what you do than what the end-user does.

-Al

To truly tighten access goes beyond the end-user!
posted by Al, Mon Nov 02 2009, 17:16
> every 90 days is still too long given today's processing power

Adam, I disagree. I do not have the greatest processer, but I can dictionary a hash at over 30,000 per second, and brute force almost that. Without a dictionary, assuming 6 characters with mixed upper case, lower case and numbers, I can crack the aformentioned in 50 hours or less.


Given that I am using my CPU and could greatly increase my cracking performance if I used my GPU, what would you suggest is a good password change age? Keep in mind, the lower the age, the more sticky notes next to the monitor and under the keyboards with their entire password list, which I believe is a much greater risk, because it is far more common.


Password experation should no longer be based on CPU/GPU brute force, which is why I believe 90 days is far to short a time. Between 180 days to never is more appropriate. This is all assuming proper account management such as disabling all terminated accounts.



-chrono13
posted by chrono13, Mon Nov 02 2009, 17:28
Bad math. That should have been 22 days for brute forcing. It is closer to a week if using a dictionary in combo with the brute force.
posted by chrono13, Mon Nov 02 2009, 17:30
I don't think requiring password changes helps any with the password reuse problem. Anecdotally it seems to just cause people to cycle through the same group of two or three passwords they use everywhere.
posted by David, Mon Nov 02 2009, 18:24
This is another pet peeve of mine. Many sites require password complexity to a degree that nobody can remember the password. This is what leads to people using sticky notes on their monitors with the password, which is exactly the opposite of what the original intent of the complex passwords really was.

In a sense it matters a lot what website you are trying to protect. For online banking, some degree of complexity can make sense. For a forum where you post pictures of your cat, probably not so much.


I would be interested in seeing a discussion of the advantages and weaknesses of various types of 2-factor authentication methods (eTokens, smartcards, etc). I used to think that they could solve a lot of problems, but I am starting to read stories from the field about vulnerabilities here as well. Even here, the answer could depend upon the situation - Windows supports the concept of using a smartcard for logon instead of the username/password, and this can provide some degree of security. Logging into a website has entirely different issues.

posted by Jack Russell, Mon Nov 02 2009, 18:53
Fair points, but seems to miss the point entirely. What exactly are you trying to protect? Complex passwords or 'password' may be acceptable depending on your risk tolerance or business needs. I'm not advocating either, but the arguments presenter here may make sense for some situation and be completly out of what in another.

I also don't' get the auditor 'gutshot' at the end of your piece. An auditor's role is to test the controls you have put in place, so while it can certainly be a pain to have someone poking around a system or network, they are only doing what you have stated is in place. If you have executive sign off that disagrees with there finding, as long as you are doing it there is no issue.
posted by Dan F, Tue Nov 03 2009, 00:34
Users sometimes shares passwords. This is one thing a password change requirement will help limit.

I agree that forced password change, even with history might result in users picking weaker passwords, but then teach them good password generation methods, of give them tools. I personally now use 1Password on my Mac and my iPhone, and use generated passwords almost everywhere.

A password on a post-in note can not be retrieved by a remote hacker. It requires somebody trusted enough to get access to the users workspace.

So in most cases, running a cracker on the password hashes a couple times per year, and force the owners of the weak passwords to change it would be a good idea. Many users uses default passwords. And if you have 5000 users, at least 100 of them have the same password, and 50 have the 2nd most popular. It is always easy to crack some passwords.

The important thing is to train the important users. Or give them the tools
posted by PHP, Tue Nov 03 2009, 07:39
One problem is security systems which force complex rules on you and you don't know what the rules are. The message is too generic. Am I aupposed to have a digit, special character or uppercase letter or all three? And what is the minimum length?

Now another problem is that I much prefer to use pass phrases which are three or five words in length. With those I don't need a digit, special character or whatever. But no, I gotta put in the useless crap.

Other places limit the password length but don't tell you that they are limited. So you happily register with a 20 character KeePass generated random password and all is well. Come back a week later and you can't get in until you reset the password and shorten it to 12 characters.

And a bank only allows me 8 character password. 8 frigging characters? Unbelievable. Mind you at least that's on an https connection.

And Windows docx and xlxs files allow a maximum of 20 characters in their passwords. <sigh>
posted by Tony Toews, Tue Nov 03 2009, 08:49
Don't know if you have seen this but this put password complexity/length in to sharp focus!

http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html
posted by Matt, Tue Nov 03 2009, 17:39
The lion's share of these posts all assume access to the hash or lack of failed login response. How does the discussion change if we assume:
- x failed login attempts triggers an alarm or other response
- the attacker does not have access to the hash
- the system is only addressable from the "internal" network
- the password in question is for a non-user account (eg. an app logging in to a database)

I've been reading NIST SP800-63 "Electronic Authentication Guideline" and NIST SP800-118 "Guide to Enterprise Password Management (Draft)" and they both seem relatively silent on non-user passwords. (much like this discussion thread)

Has anyone seen any vetted recommendations on the rotation passwords tied to non-user accounts? Specifically, non-user interfaces between application or infrastructure components?
posted by Interface Admin, Tue Nov 03 2009, 21:38
Many here are against sticky notes, but I PREFER them:
Having a weak password is much worse than a good and very strong password which must be written on a sticky note since it _is_ impossible to remember. Most have them in their mind after about one or two month of daily usage. However I suggest them to put _that_ note under the keyboard or in the desk drawer so it is not visible from outside just by looking through the window.

For users which must have a strong password (10 characters, upper+lower+number, admin password longer) I do create them, and we write it up, and we keep a list which user has which password. Not all users (and companies) need such passwords, I only use that sadistic password rule for any account that has access from the outside without VPN, or with VPN from an "unknown" non-controlled machine.

To get the list, or one user password, someone has to break in the house, and once someone is IN the house it does not matter since he simply can take all the hardware he needs which makes any password useless. And in case of the list (with the admin password) some one has to take a safe with a few hundred kilos, fixation to the ground and wall, with them + still be faster than the police.
posted by Jou, Wed Nov 04 2009, 07:09
Some years ago, I try to change the 30/60/90 password aging policy at my place (and failed). I didn't found much information on Internet to convince.
I agree more work need to be done on improving user knowledge about how to make good passwords, avoiding password sharing and enforcing good accounts management. If it is applied, you can have password expiration in years with no problem.

Few links i found
http://www.itsecurity.com/blog/20071008/password-policy-are-the-usual-best-practices-wrong/
http://www.mccune.org.uk/blog/000460.html
http://listserv.educause.edu/cgi-bin/wa.exe?S2=SECURITY&q=password+aging&s=&f=&a=&b=

Few Official policies
(down)http://www.uncfsu.edu/itts/networking/passwords.htm 180d
http://west.wwu.edu/atus/web/pwordaging.shtml 120d
(down)http://www.pasteur.fr/infosci/utilinfo/HOWTO/passwd.html 1/year
http://www.it-sudparis.eu/s2ia/unix/mode-d-emploi/change-passwd.htm 6-12 months
(down)http://www.nusnet.nus.edu.sg/accounts/useraccount.htm 1/6 months
http://ucis.dal.ca/helpdesk/faq/password_expiry.html 1/year
posted by Julien, Wed Nov 04 2009, 09:33
To "Interface Admin's" question about non-user accounts, I can point to a number of previous assignments in which a service account's password was exposed. Because the password had not been changed in years, it was deemed 'too dangerous' to change the password without spending several months investigating what services and applications used the password.
View password changes as a "mini disaster recovery exercise", to demonstrate that you have working processes in place for changing passwords when you need to do so in a hurry.
I go into a little more detail at http://msmvps.com/blogs/alunj
posted by Alun Jones, Wed Nov 04 2009, 18:39
As others have said time and time again, the actual password rules are often inadequate. Most requirements don't improve security or, worse still, downgrade it. The fact is that easily remembered passwords such as "under-the-volcano", or even more simply "ping-pong-pang" or "dd-cc-bb-aa" are strong. The problem with these, of course, is that examples are needed to explain the principle and naive users will simply copy one of these.
posted by ForgeT, Wed Nov 04 2009, 23:09
Now, I'm not a bigshot in my company, but from my understanding of security, I'd do the following:
Assert two extremes:
1) Organized, forceful attacker, who will guess passwords "fast", which is asserted to be ~1 week - this is with weak password, and a forcebrute attack. I don't know whether it is realistic. I'm just throwing it out there.
2) Disorganized, social-engineering-ish attack which hit the one-in-a-million user or never really amount to anything. General time to get a single password is probably about 25 years as is asserted in this story.

Using these two, we assert that either may come our way (more or less depending on size and popularity of cooperation - I assume that MS gets a lot of bruteforce attacks for instance).

To properly resolve (1) we'd need to change passwords every week. Doing this would prove a huge burden for every single user, which even the most paranoid security person will agree is excessive (I'd think).
To properly resolve (2) we just have to use fairly strong password policy (8 alphanumeric characters, at least one special symbol (!#_: etc.), small and large letters, and at least one digit.).
To resolve them both in a fair way would be to take some kind of average between the two based on how often (1) occurs and how good we (the IT-department) are at intercepting said attempts.
The better we are and the less it occurs the closer we get to 25 years reset time, and the more it happens and the worse we are, the closer we get to once per week.
Assuming proper security precautions for #2 is in place, I'd wager the cracking time for a password (even if you've got the hash) escalates into about a year or more before one can crack a single password. Optimally (or at least from what my brain can cope with right now), that'd mean an on-average password reset time of about a year.

I believe, thus, that once per year would be fair - perhaps a friendly message once half a year has passed to the user. This will encourage users to figure out smart, difficult and unique passwords each time and on the same time, make sure they don't have to change it with such a frequency that they end up writing them down and thus dramatically lowering security.

Thoughts?
posted by redit, Fri Nov 06 2009, 12:28
Login here to post a comment. Diary Archive