Password Policies

We’re at 90 days which was the recommendation from our financial auditors.  Seemed like a reasonable period of time to the team making the decision and so we accepted it and sold it to the University community.  A few detractors would like us to eliminate any password change requirement but they are a very, very small majority.

The University of Arizona NetID password standard is at http://security.arizona.edu/sites/default/files/ISS703U.pdf.  Privileged accounts in the enterprise Active Directory have a different standard but I don’t have a public URL for the standard.  The lifetime of privileged account passwords is shorter than non-privileged account passwords.

In Changing Passwords (http://www.schneier.com/blog/archives/2010/11/changing_passwo.html), Bruce Schneier says, “The downside of changing passwords is that it makes them harder to remember. And if you force people to change their passwords regularly, they're more likely to choose easy-to-remember -- and easy-to-guess -- passwords than they are if they can use the same passwords for many years. So any password-changing policy needs to be chosen with that consideration in mind.”

I wish we’d stop saying password.  Words are short and relatively simple.  I wish we’d say pass-key, passphrase, “authorization-expression” and anything but word.  I blogged about Passwords, Passphrases and Pass-acronyms (http://blog.ericcase.com/2010/03/passwords-passphrases-and-pass-acronyms.html) two and half years ago, but it’s was nothing new.

-Eric

Steve,

  We are at 90 days for all faculty and staff.  Six years ago, the timing was 30 days for everyone (including students), but that was deemed problematic for a myriad of reasons.  The 90 days still fit within acceptable guidelines.

Best regards,

Kev

Thank you Eric for bringing up Bruce Schneier’s post on this topic. I’d like to point to an item near the bottom of that post where he points to research done by UNC and Microsoft that looks at a key principle cited by advocates of frequently changing passwords. see

The Security of Modern Password Expiration: An Algorithmic Framwork and Empirical Analysis."

It was some of the first research I had seen when the discussion would start up on which is the greater problem: changing passwords frequently (people write them down, use weak passwords, etc) versus change frequently (that way a thief has only a fixed amount of time to use it).

Regards, Marg

Steve-

We use complex passwords and have our expiration set to 180 days…this is written into university policy.

Brian

Brian A. Young

Vice President and CIO

Creighton University

Omaha, NE 68178

4022802202

bay@creighton.edu

Twitter: http://twitter.com/#!/Cujays

LinkedIn: http://www.linkedin.com/pub/brian-young/1/863/2b7

On 09/25/2012 09:00 PM, Steve Hall wrote:

I’m reviewing our password reset policy.  Currently our policy is to require users, via password expiration,  to change their password every 60 days.  Based on anecdotal evidence I gathered from faculty and staff who have recently come to Knox from other I believe our reset interval is shorter than most other Colleges and Universities.  However, I have gotten answers that range from 30 days to annually, and a single, “I never had to change my password…”. 

We also have complexity and history policies in place, but the one I am most frequently “challenged” on the expiration period.  Would any of you be willing to share what your expiration period is?   If it is 90 days or under would you also share your rationale?

Thanks,

Steve

Steven S. Hall

Vice President & Chief Information Officer
KNOX COLLEGE – Information Technology Services
2 East South Street | Galesburg, IL 61401
Tel 309.341.7823 | Fax 309.341.7099

shall@knox.edu | www.knox.edu

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Given the ease with which passwords (and passphrases) can be broken/discovered (see the link below), I’m becoming more convinced than ever that passwords and passphrases should be replaced as a means of securing sensitive information.  Even salted hashes are insufficient in the face of the latest generation of rainbow table attacks.  While I recognize the difficulty (and expense) of doing so, I’m advocating replacing our current password based authentication mechanisms.

http://arstechnica.com/security/2012/08/passwords-under-assault/

Two factor authentication schemes, properly implemented, can’t be deployed soon enough IMO.

Gordon

Gordon D. Wishon

Chief Information Officer

Arizona State University

Password expiration has a negligible effect on limiting mischief.  The ability to steal passwords implies privileged access to your systems or network.  If the attacker has administrator access to the password database (AD, etc.) or the ability to sniff traffic on your network, he can install backdoors or continuously steal passwords in order to avoid the 60 day window.  That’s assuming he even needs continued access to accomplish his goal.

What threat model does password expiration protect against?  One possibility is where an attacker wants to steal credentials so that he can resell them.  With a short expiration (e.g. 60 days), the value of the passwords would depreciate quickly and some of the passwords might expire before the buyer is able to make use of them.    But, this assumes some disorganization on the part of the buyer or seller.  If the seller is able to pass the data on quickly and the seller is organized and ready, the expiration will have a very minimal impact on their operation.

In other cases, there is even less of a benefit.  If the attacker wants to maintain access to the system (and doesn’t have another way of doing so) he only needs to re-steal the passwords about once a month (assuming a 60-day expiration).  If he just wants to steal the data on your systems, the passwords are only relevant to the extent that they help him get to the data.  Once he has the data, the passwords don’t matter.  If he wants to use the passwords to break into other sites, he doesn’t care about the expiration policy at your site.  If the attacker wants to deface your website or use your network to launch an attack against someone else, he probably doesn’t plan on having long-term access.  

The benefit from password expiration seems very small compared to the consequences: weaker passwords, increased support, etc.  I think we’re better off requiring stronger passwords and using more effective policies and practices such as disabling inactive accounts, not sharing root/Administrator accounts, never transmitting passwords in the clear and possibly using two-factor authentication. 

Gene Spafford wrote about password expiration on the CERIAS blog several years ago.  It’s worth reading:

http://www.cerias.purdue.edu/site/blog/post/password-change-myths/

I’ve also written a lot about passwords on my blog:

http://bugcharmer.blogspot.com/2012/06/passwords-attacks-and-threats.html

Regards,

It’s GPU-based password crackers more than rainbow tables that are the current problem.  Password salting will prevent anyone from using rainbow tables as long as the salt value is large.  With a fast hashing algorithm (e.g. MD5, SHA-1), a GPU-based password cracker can make billions of guesses per second.  Salting the passwords helps a little since the attacker will have to target accounts one at a time, but that’s fairly practical when the hash is fast.  With a strong (i.e. slow, salted) password hash such as bcrypt, scrypt, or PBKDF2, passwords hold up fairly well.

That said, I agree about two-factor authentication.  It changes the game.

Regards,

Bob,

Thanks for your insight.  You’ve identified exactly the scenario we experienced a few years ago,  which put me on the path of shorter expiration policies.  It used to be 30 days before I caved to 60 days under duress for people again pushing for no or annual resets.  I’m going to send along a message about our experience to see if it was an edge case that I am overreacting to or something that most people tend to ignore because frequent password resets are perceived to be a hassle for end user support organizations.

Best,

Steve

First, I’d like to apologize in advance for this long message.  Second, Thanks everyone,  I appreciate the responses as well as the  opinions offered about the viability of passwords as a mechanism for securing accounts and the wisdom, or lack thereof, in resetting them.  I’d love to move to some form of two factor authentication. But, it isn’t in the budgetary cards at this time.

We require complex passwords, have password history and complexity polices, and disable accounts for 15 minutes after the third successive unsuccessful login attempt...  We do try to follow best practice.   I don’t perceive that we are getting passwords cracked or stolen because they are written down in any great number.   What we are dealing with is people who simply respond positively to any request to supply their username and password… phishing.   We’ve taken a number of remedial actions to this… but our least sophisticated users or those new to our community always present an educational challenge that cannot be overcome 100% or in a time frame to prevent this.  September is always a challenge!

What we have discovered is that some of the compromised accounts are immediately used for sending spam and some are not.  A couple of years ago we had a very credible phishing message fool several users.  We went about cleaning  up as usual… two or three accounts compromised and just about the time we’d get off all the blacklists the bad guys would grab three more accounts and start sending spam again… yes, outbound filtering, rate limiting, …. are in place.  Eventually, we had to expire every  end user password to stop the madness.  Because we didn’t have a short (one year) password reset cycle, we had a number of end users who had forgotten or  relied on our help desk to assist in password resets.  It became quite a production.  The voluntary request for people to reset passwords wasn’t ignored… but it was the least sophisticated users who failed to comply with the request… exactly the population most susceptible to the scam.  Those who reset their passwords voluntarily weren’t the ones likely to fall for the scam anyway.

I suppose I’ve always known this, but the take away is that in  large population of users there is always some percentage of accounts that are compromised.  Not all accounts are immediately used to send Spam or do something that immediately triggers detection.  I am convinced that some are just monitored… a forward placed on an e-mail account… to see what windfall may eventually come. 

Figure out what banking or credit card site a person uses, get their username on that site, request a password reset that sends the new password or link for reset via e-mail, and bingo, you’re in and can be up to plenty of mischief.   I know of some people who make the habit of using the same password on many sites… so figure out the sites they use and try the compromised password there.    My assertion:  The longer the compromised account remains so, the higher the probability of information leaking out that could inflict personal or institutional harm.  SSO,  Oh my!

I believe this is a real threat.  The only way I know to end illicit access to  resource that is protected by a password is to change the password. If you believe, as do I, that there are some number of accounts always compromised,  lurking out there undetected… then see the previous sentence.   I am often amazed, perhaps alarmed is a better word, at the information people will send in e-mail.  It is this threat that I am looking to mitigate by having regular password resets.   The bonus,  if passwords are reset on some sufficiently short recurring basis our end users will  remain familiar with the process.   If the need to call “broken arrow” arises and mass expirations of a large numbers of passwords is the response it won’t turn into a crisis as many users are locked out until they can get through to the help desk.   YES… Our instructions for password resets are on a public facing web site!!!

I realize my epistle more than anything points out the inherent inadequacies in passwords as a security mechanism.  But, until something better becomes widely available and within reach this is what many of us have.  What  I’m looking for from my colleagues here is this;  Does anyone else perceive this threat?  Am I being overly cautious? Is there something I am completely overlooking in mitigating this issue?  I really do, just for my own peace of mind, hope there is something I’m missing.  I have, on occasion, lost sleep over this!

Thanks,

Steve

Steven S. Hall

KNOX COLLEGE – Information Technology Services
2 East South Street | Galesburg, IL 61401
Tel 309.341.7823 | Fax 309.341.7099

shall@knox.edu | www.knox.edu

Steve,

While it may be necessary to expire all passwords after some incident, I don’t think it helps security to have an ongoing expiration, especially a short one.  It has no effect on attackers who only need short-term access or who are able to secure continued access by re-stealing passwords or installing backdoors.  In many cases, an attacker who does rely on passwords for continued access may be able to crack new passwords using  knowledge of the old ones.  There’s a good paper about this here (you can safely skip sections 3 and 4):

http://cs.unc.edu/~fabian/papers/PasswordExpire.pdf

Password expiration can also encourage users to pick weaker passwords or to write them down and store them insecurely:

http://hornbeam.cs.ucl.ac.uk/hcs/people/documents/Angela%20Publications/1999/p40-adams.pdf

I won’t say there is never any benefit.  In narrow circumstances, it may help.  But, overall, I think expiration makes the situation worse, not better.  I’ve posted a much longer response to this issue, which includes some of my previous comments on this thread, here:

http://bugcharmer.blogspot.com/2012/09/password-expiration.html

Regards,