Main Nav

CIO Digest - 21 Oct 2013 to 23 Oct 2013 (#2013-266)

At the insistence of our auditors, we have a 120-day password expiration policy at our institution. We also enforce password complexity requirements and account lockouts after a certain number of failed login attempts. Our password aging policy is quite unpopular at our institution and our users take all sorts of measures like minor sequential number increments to cope. Who can blame them?

 

We have been researching this recently and the evidence seems mixed. There seems to be as good evidence showing the value of password aging as there is evidence showing that it is a big waste of time. I’d like to hear how you folks are handling this question.

 

Thanks.

-----------------------------------

Tunde Giwa

Chief Technology Officer

The Juilliard School

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

Comments

We are in the process of discussing this as well, based on auditors remarks. Our campus login and ID policy is divided between network logins and ERP (different). We expire after 30 days the information system so administrative types have been used to changing passwords for some time. General network login is a different matter. We are discussing strong password requirements (we currently do have self-service password change/update in place with challenge questions included) but are not certain whether expiration will be part of the changes implemented. Would also like to hear how others are dealing with this. Tom Thomas H. Carnwath | Vice President | Technology and Information Services The University of the Arts | 320 South Broad Street | Philadelphia, PA 19102 | Tel: 215-717-6440 [cid:9A00AEAA-C16F-4EFD-8799-9C6309C3840F] Need Assistance? Call Oops (215-717-6677) to get answers. OTIS will never ask for your personal information or password in an email. Never share this information with anyone. This message and any attachment may contain confidential or privileged information and is intended for the intended individual named as addressee. If you are not the intended recipient of this message, please notify the sender immediately by return email and delete this message and all attachments from your system. Any unauthorized disclosure, use, distribution, or reproduction of this message or any attachments is prohibited and may be deemed unlawful. Please consider the environment before printing this email. From: Tunde Giwa > Reply-To: The EDUCAUSE CIO Constituent Group Listserv > Date: Thursday, October 24, 2013 10:49 AM To: "CIO@LISTSERV.EDUCAUSE.EDU" > Subject: [CIO] Passwords: To Age or not to Age? At the insistence of our auditors, we have a 120-day password expiration policy at our institution. We also enforce password complexity requirements and account lockouts after a certain number of failed login attempts. Our password aging policy is quite unpopular at our institution and our users take all sorts of measures like minor sequential number increments to cope. Who can blame them? We have been researching this recently and the evidence seems mixed. There seems to be as good evidence showing the value of password aging as there is evidence showing that it is a big waste of time. I’d like to hear how you folks are handling this question. Thanks. ----------------------------------- Tunde Giwa Chief Technology Officer The Juilliard School ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
CIO Digest - 21 Oct 2013 to 23 Oct 2013 (#2013-266)

Auditors are like attorneys: ask ten of them for a recommendation on something and you’ll get 12 responses…. And then they’ll still complain even if you take the recommendation….

 

Sorry, too many auditor and lawyer meetings lately….. 8-)

 

Thanks!

******************************************
Charlie Moran
Sr. Partner & CEO

1215 Hamilton Lane, Suite 200
Naperville, IL  60540
Toll-Free (877) 212-6379 (Voice & Fax)
Website: 
www.MoranTechnology.com
******************************************
P Please consider the environment before printing this email...

 

We do 180 days for everyone on their NetIDs. It kind of straddles the fence between "we must be able to check off the 'has password expiration' box" and "password expiration is a waste of time." 

We have a script that emails folks several times leading up to the password expiration, and we have self-service password change and password reset.

Having password expiration came in handy for us recently. When we increased our password length and complexity requirements a few months ago, we decided that rather than forcing everyone to change their passwords all at once, we would just let it ease in gradually as people's passwords expired (or they forgot them and had to reset them). This has worked out quite well, so far.

--Dave



--

DAVID A. CURRY, CISSP • DIRECTOR OF INFORMATION SECURITY

THE NEW SCHOOL • 55 W. 13TH STREET • NEW YORK, NY 10011

+1 212 229-5300 x4728 • david.curry@newschool.edu



We also have a 120 day password expiration policy and enforce password complexity requirements. The auditors like this, but the employees do not and of course we see passwords written on the monitor and keyboard. We are thinking about increasing the password length, but also increasing the expiration time to 180 days. Will this increase user satisfaction as well as security or does the increase in password length create as much frustration as the shorter password expiration did? I was thinking about polling campus to find out what they would prefer. Q1 What password requirements would make having a secure password easier to manage? A. Longer password lasting 180 days B. Shorter password expiring 120 days C. No preference Q2 Why do did select the answer in Q1 A. Both ways will equally secure my data B. The longer password is equally as difficult as changing my password more often C. It is harder for me to remember longer passwords D. It is harder for me to remember constantly changing passwords Can we keep shorter passwords with longer expiration dates by changing the way we implement account lockouts? Are others using an account lockout after x number of failed login attempts? Does this automatically reset itself after a time frame or do you need staff intervention? We are considering modifying our lockout period after 20-25 failed attempts which will automatically unlock itself after specific (TBD) time frame. This should be enough for someone who has to try several old passwords, but still put a road block for automated password guesses. There is a concern that if an account is under fire this could prevent a legitimate user from accessing their account. We are looking at how to get around that obstacle. James Farr Information Security Officer Utica College
Tunde,

At UDayton, we previously had a complex password requirement with a very long aging process -- every 5 years.  However, we recently completed an external security assessment and our consultants strongly urged us to require a minimum of 2 times a year for general users and every 90 days for IT staff.  We also looked at those studies that debated the benefits and many of us sided with a more complex password standard tied to two-factor authentication.  While we are moving toward the two-factor strategy, until we get there, we decided to implement the new aging process so that we are "covered" for liability issues in terms of "current best practices."  

In a university setting, we view the threat of key-loggers as a substantial risk that is not solved with password aging or password complexity.  We've concluded that an authentication token is our best and most efficient defense to protect faculty credentials - short of removing all classrooms systems.  We'd love to learn how others have solved this.

Thanks
Tom


Thomas Skill, Ph.D.
Associate Provost & CIO
Professor of Communication
Office (937) 229-3511
Fax (937) 229-4044

eMail: skill@udayton.edu

UDit
University of Dayton
300 College Park 
Dayton, OH 45469-2230


A recent IAM Online webinar covered the topic of "passwords and beyond". American University presented a case study on their recent password policy changes. The slides, along with a recording, are available here: http://www.incommon.org/iamonline/. Thank you, Valerie Valerie Vogel Program Manager EDUCAUSE Uncommon Thinking for the Common Good direct: 202.331.5374 | main: 202.872.4200 | educause.edu From: Thomas Skill > Reply-To: "cio@listserv.educause.edu" > Date: Thursday, October 24, 2013 8:44 AM To: "cio@listserv.educause.edu" > Subject: Re: [CIO] Passwords: To Age or not to Age? Tunde, At UDayton, we previously had a complex password requirement with a very long aging process -- every 5 years. However, we recently completed an external security assessment and our consultants strongly urged us to require a minimum of 2 times a year for general users and every 90 days for IT staff. We also looked at those studies that debated the benefits and many of us sided with a more complex password standard tied to two-factor authentication. While we are moving toward the two-factor strategy, until we get there, we decided to implement the new aging process so that we are "covered" for liability issues in terms of "current best practices." In a university setting, we view the threat of key-loggers as a substantial risk that is not solved with password aging or password complexity. We've concluded that an authentication token is our best and most efficient defense to protect faculty credentials - short of removing all classrooms systems. We'd love to learn how others have solved this. Thanks Tom Thomas Skill, Ph.D. Associate Provost & CIO Professor of Communication Office (937) 229-3511 Fax (937) 229-4044 eMail: skill@udayton.edu Twitter: https://twitter.com/skilltd Linkedin: http://www.linkedin.com/in/skilltd UDit University of Dayton 300 College Park Dayton, OH 45469-2230
We were recently having this same discussion. We have a 180 day expiration on all accounts and it drives users (mostly students) and us crazy when they have three, four or five other devices setup to use that password. It expires, they pick a new one, and unless they change all other devices almost immediately those devices start attempting to logon with the old password and temporarily disable the account. We were actually talking about changing student accounts to never expire and replace it with education on why you should change passwords on some set schedule that makes sense to the account holder. For faculty the most problems come into play when their password expires over the summer and first day back in August we get flooded with calls for people who can't sign on. We realized in our discussions that banks never force a password change, banks never force a PIN change, stock trading sites do not require a password change, Amazon does not require a password change, no one could think of any ecommerce site, that is holding your credit card information, that forced a password change. Even my health insurance and medication subscription site does not require me to change my password. So why do we make students change a password? Mike Cunningham VP of Information Technology Services/CIO Pennsylvania College of Technology -----Original Message----- From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Valerie Vogel Sent: Thursday, October 24, 2013 11:52 AM To: CIO@LISTSERV.EDUCAUSE.EDU Subject: Re: [CIO] Passwords: To Age or not to Age? A recent IAM Online webinar covered the topic of "passwords and beyond". American University presented a case study on their recent password policy changes. The slides, along with a recording, are available here: http://www.incommon.org/iamonline/. Thank you, Valerie Valerie Vogel Program Manager EDUCAUSE Uncommon Thinking for the Common Good direct: 202.331.5374 | main: 202.872.4200 | educause.edu From: Thomas Skill > Reply-To: "cio@listserv.educause.edu" > Date: Thursday, October 24, 2013 8:44 AM To: "cio@listserv.educause.edu" > Subject: Re: [CIO] Passwords: To Age or not to Age? Tunde, At UDayton, we previously had a complex password requirement with a very long aging process -- every 5 years. However, we recently completed an external security assessment and our consultants strongly urged us to require a minimum of 2 times a year for general users and every 90 days for IT staff. We also looked at those studies that debated the benefits and many of us sided with a more complex password standard tied to two-factor authentication. While we are moving toward the two-factor strategy, until we get there, we decided to implement the new aging process so that we are "covered" for liability issues in terms of "current best practices." In a university setting, we view the threat of key-loggers as a substantial risk that is not solved with password aging or password complexity. We've concluded that an authentication token is our best and most efficient defense to protect faculty credentials - short of removing all classrooms systems. We'd love to learn how others have solved this. Thanks Tom Thomas Skill, Ph.D. Associate Provost & CIO Professor of Communication Office (937) 229-3511 Fax (937) 229-4044 eMail: skill@udayton.edu Twitter: https://twitter.com/skilltd Linkedin: http://www.linkedin.com/in/skilltd UDit University of Dayton 300 College Park Dayton, OH 45469-2230
Valerie is right to point out this resource. 

One of the things we did at UMBC is work with our auditors to educate them on the NIST 800 standards. NIST is chartered by the federal government to develop best practice for the government and they have a rigorous and scientific validated approach (peer reviewed) to the work they do. Whereas auditors could say best practice was "N" days there is in fact no backup to that and if you take that to the logical conclusion the limit should "0" and we all use a set of one-time passwords :-)

The NIST 800-63 standard was revised as 800-63-2 and here is a draft, http://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf

If you go to page 102 in the actual NIST publication (Appendix A) they walk you through calculating password strength using their methodology.

What is very helpful, though a bit technical, is looking at one of the early password entropy calculators that NIST developed -- http://bit.ly/HhkbVk

The calculators let you evaluate the benefit of different rules -- how much strength do you gain by going from 90 to 180 (not much) versus increasing the complexity or length.  We used this to develop our password policies. We had an unbiased tool that could show the auditors that our passwords rules were stronger than their rules, even though the change limit was longer due to compensating controls such as restrictions on the letter combinations and length that were more rigorous.  

Using NIST, conceivably we could go many years before we force a password change.  We track failed password attempts and we force passwords to be changed when they meet a value we feel is to great for that users risk level. In this way we can have different rules for students, faculty, and staff based upon risk to the institution. Saying that, we do try to force password changes every two years.

We are in the process of transitioning to multi-factor for higher risk users (mostly staff in IT, power users, others with higher risks) and this will help eliminate some of the issues with passwords for power users.  If you are interested in multi-factor, look at this IAMonline, http://internet2.adobeconnect.com/p9pjt3ncks9/  that took place in September 2013.

jack


Jack Suess             UMBC VP of IT & CIO
jack@umbc.edu     1000 Hilltop Circle
410.455.2582          Baltimore Md, 21250
Homepage:             http://bit.ly/fSB5ID



Passwords are one of my favorite topics. Password ageing is now more tradition than security. In the early days of computing, passwords were stored as clear text in the UNIX password file, then as encrypted cipher text (Morris & Thompson, 1979) and the password file was readable by everyone in order to display file ownership, etc. (“Linux Password & Shadow File Formats,” n.d.). This meant everyone with access to the system had access everyone’s encrypted password and could try a decrypt them. Until the system designers and administrators figured out how to protect the encrypted passwords (about 1987), they made passwords expire before anyone had enough time to decrypt them. The NIST “Guide to enterprise password management (draft)” (SP 800-118) says, “Password expiration is also a source of frustration to users, who are often required to create and remember new passwords every few months for dozens of accounts, and thus tend to choose weak passwords and use the same few passwords for many accounts” (Scarfone, Souppaya, & Kent, 2009, p. ES–2). Given that, encrypted passwords are better protected and we are not at the mercy of brute force decryption, password-aging servers a smaller purpose. It may help when a password is unknowingly compromised. I say my help because the attacker may reacquire the password using the same technology used to acquire the original password (Scarfone et al., 2009) or use knowledge of the old password to guess the new password as (Zhang, Monrose, & Reiter, 2010) have shown. It also allows changes in password policy to be rolled out “naturally” as users change their password. However, that can be done without ageing passwords. I like Cormac Herley’s (Microsoft Research) quote, “[Security] advice offers to shield [users] from the direct costs of attacks, but burdens them with far greater indirect costs in the form of effort” (2009, p. 1) Another good quote is “In minimising password change, participants are being completely reasonable: changing passwords places a heavy burden on users, both in devising a new password and also in learning them” (Inglesant & Sasse, 2010, p. 5). With all this said I think Bruce Schneier has the best advice. So in general: you don't need to regularly change the password to your computer or online financial accounts (including the accounts at retail sites); definitely not for low-security accounts. You should change your corporate login password occasionally, and you need to take a good hard look at your friends, relatives, and paparazzi before deciding how often to change your Facebook password. But if you break up with someone you've shared a computer with, change them all. (https://www.schneier.com/blog/archives/2010/11/changing_passwo.html) -Eric References Herley, C. (2009). So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users, 133–144. Retrieved from http://apps.isiknowledge.com/full_record.do?product=UA&search_mode=Gener... Inglesant, P., & Sasse, M. A. (2010). The True Cost of Unusable Password Policies: Password Use in the Wild, 383–392. Retrieved from http://apps.webofknowledge.com.ezproxy2.library.arizona.edu/full_record.... Linux Password & Shadow File Formats. (n.d.). Retrieved September 25, 2013, from http://www.tldp.org/LDP/lame/LAME/linux-admin-made-easy/shadow-file-form... Morris, R., & Thompson, K. (1979). Password security: A case history. Communications of the ACM. Retrieved from http://dl.acm.org/citation.cfm?id=359172 Scarfone, K., Souppaya, M., & Kent, K. (2009). Guide to enterprise password management (draft) recommendations of the National Institute of Standards and Technology (Vol. 118). Gaithersburg, MD :: U.S. Dept. of Commerce, National Institute of Standards and Technology,. Retrieved from http://universityofarizona.worldcat.org.ezproxy1.library.arizona.edu/tit... Zhang, Y., Monrose, F., & Reiter, M. (2010). The security of modern password expiration: An algorithmic framework and empirical analysis. … Computer and communications security. Retrieved from http://dl.acm.org/citation.cfm?id=1866328 IT professionals will never ask for your password – not in email – not over the phone, never. Eric Case, CISSP MIS PhD student and DHS CDG Fellow ecase (at) email (dot) arizona (dot) edu http://www.linkedin.com/in/ericcase -----Original Message----- From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mike Cunningham Sent: Thursday, October 24, 2013 9:28 AM To: CIO@LISTSERV.EDUCAUSE.EDU Subject: Re: [CIO] Passwords: To Age or not to Age? We were recently having this same discussion. We have a 180 day expiration on all accounts and it drives users (mostly students) and us crazy when they have three, four or five other devices setup to use that password. It expires, they pick a new one, and unless they change all other devices almost immediately those devices start attempting to logon with the old password and temporarily disable the account. We were actually talking about changing student accounts to never expire and replace it with education on why you should change passwords on some set schedule that makes sense to the account holder. For faculty the most problems come into play when their password expires over the summer and first day back in August we get flooded with calls for people who can't sign on. We realized in our discussions that banks never force a password change, banks never force a PIN change, stock trading sites do not require a password change, Amazon does not require a password change, no one could think of any ecommerce site, that is holding your credit card information, that forced a password change. Even my health insurance and medication subscription site does not require me to change my password. So why do we make students change a password? Mike Cunningham VP of Information Technology Services/CIO Pennsylvania College of Technology -----Original Message----- From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Valerie Vogel Sent: Thursday, October 24, 2013 11:52 AM To: CIO@LISTSERV.EDUCAUSE.EDU Subject: Re: [CIO] Passwords: To Age or not to Age? A recent IAM Online webinar covered the topic of "passwords and beyond". American University presented a case study on their recent password policy changes. The slides, along with a recording, are available here: http://www.incommon.org/iamonline/. Thank you, Valerie Valerie Vogel Program Manager EDUCAUSE Uncommon Thinking for the Common Good direct: 202.331.5374 | main: 202.872.4200 | educause.edu From: Thomas Skill > Reply-To: "cio@listserv.educause.edu" > Date: Thursday, October 24, 2013 8:44 AM To: "cio@listserv.educause.edu" > Subject: Re: [CIO] Passwords: To Age or not to Age? Tunde, At UDayton, we previously had a complex password requirement with a very long aging process -- every 5 years. However, we recently completed an external security assessment and our consultants strongly urged us to require a minimum of 2 times a year for general users and every 90 days for IT staff. We also looked at those studies that debated the benefits and many of us sided with a more complex password standard tied to two-factor authentication. While we are moving toward the two-factor strategy, until we get there, we decided to implement the new aging process so that we are "covered" for liability issues in terms of "current best practices." In a university setting, we view the threat of key-loggers as a substantial risk that is not solved with password aging or password complexity. We've concluded that an authentication token is our best and most efficient defense to protect faculty credentials - short of removing all classrooms systems. We'd love to learn how others have solved this. Thanks Tom Thomas Skill, Ph.D. Associate Provost & CIO Professor of Communication Office (937) 229-3511 Fax (937) 229-4044 eMail: skill@udayton.edu Twitter: https://twitter.com/skilltd Linkedin: http://www.linkedin.com/in/skilltd UDit University of Dayton 300 College Park Dayton, OH 45469-2230

This is an oft debated topic on the Security list as well.

 

I’ve spent the past few years in a security role, and I was often asked to explain why we expired passwords.  

 

The honest answer is “Because we don’t have a better solution in place.” One time passwords would win this argument hands down if they were common, easy, and unobtrusive.

 

Notre Dame expires passwords every 180 days, and has a strong password policy which is somewhat restricted due to a number of legacy systems that don’t handle specific types of characters or which introduce password length limitations. We have done peer studies, and we fit well within the middle of the pack on complexity standards, and align with about a quarter of our study group on expiration timeframe.

 

Here’s what password aging does buy us:

 

-          Aging passwords helps to prevent our students, faculty, and staff from using the same password for everything. Since they are unlikely to change their password for cloud services every 180 days, their netID password tends to be somewhat different. It is very informative to ask a group of undergraduates if they use different passwords for all of their critical services.

-          Compromised passwords, which have been one of our biggest threats in recent years, tend to be collected and used at a later date. Aging passwords helps to prevent this from becoming a multi-year issue for our accounts, particularly our vulnerable and often targeted retiree and emeritus population.

-          It helps to discourage the sharing of passwords in some cases, or to limit the scope of password sharing as they have to re-distribute the password every time they change it. (it’s against our policies to share passwords, but it happens!)

 

Password aging costs us:

 

-          Time to do password resets via our helpdesk for those who forget what they just changed it to.

-          A handful of cranky emails a year that get reasonable responses with information like what I shared above. Our helpdesk has the response template at this point!

 

A better solution, and one that I think many of us will head toward in the mid to long term is to use one time passwords for anything that is sensitive, for access to our VPNs, and for most IT staff who have greater access to infrastructure. Our nearly ubiquitous smartphones combined with one time password tools like Duo (which has a Net+ agreement in place) will help us get there, but we’re not there yet.

 

David

 

David Seidl

Senior Director of Campus Technology Services

Office of Information Technologies

University of Notre Dame

Notre Dame, IN 46556

(574) 631-7305

dseidl@nd.edu

 

 

 

From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jack Suess
Sent: Thursday, October 24, 2013 12:38 PM
To: CIO@LISTSERV.EDUCAUSE.EDU
Subject: Re: [CIO] Passwords: To Age or not to Age?

 

Valerie is right to point out this resource. 

 

One of the things we did at UMBC is work with our auditors to educate them on the NIST 800 standards. NIST is chartered by the federal government to develop best practice for the government and they have a rigorous and scientific validated approach (peer reviewed) to the work they do. Whereas auditors could say best practice was "N" days there is in fact no backup to that and if you take that to the logical conclusion the limit should "0" and we all use a set of one-time passwords :-)

 

The NIST 800-63 standard was revised as 800-63-2 and here is a draft, http://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf

 

If you go to page 102 in the actual NIST publication (Appendix A) they walk you through calculating password strength using their methodology.

 

What is very helpful, though a bit technical, is looking at one of the early password entropy calculators that NIST developed -- http://bit.ly/HhkbVk

 

The calculators let you evaluate the benefit of different rules -- how much strength do you gain by going from 90 to 180 (not much) versus increasing the complexity or length.  We used this to develop our password policies. We had an unbiased tool that could show the auditors that our passwords rules were stronger than their rules, even though the change limit was longer due to compensating controls such as restrictions on the letter combinations and length that were more rigorous.  

 

Using NIST, conceivably we could go many years before we force a password change.  We track failed password attempts and we force passwords to be changed when they meet a value we feel is to great for that users risk level. In this way we can have different rules for students, faculty, and staff based upon risk to the institution. Saying that, we do try to force password changes every two years.

 

We are in the process of transitioning to multi-factor for higher risk users (mostly staff in IT, power users, others with higher risks) and this will help eliminate some of the issues with passwords for power users.  If you are interested in multi-factor, look at this IAMonline, http://internet2.adobeconnect.com/p9pjt3ncks9/  that took place in September 2013.

 

jack

 


Jack Suess             UMBC VP of IT & CIO
jack@umbc.edu     1000 Hilltop Circle
410.455.2582          Baltimore Md, 21250

Homepage:             http://bit.ly/fSB5ID

 


Password strength and password aging are completely separate strategies to mitigate completely separate attacks.  They deserve separate analyses and policies.

Password strength or complexity makes it harder to guess the password. The details of what is "strong enough" will depend on the nature of the attack (random guessing or dictionary guessing) and very much on how many guesses can be tried -- a system that inserts a timed pause after X number of failed guesses will dramatically reduce the potential number of attempts and improve the resistance of passwords.

Password aging, OTOH, seeks to prevent damage AFTER the password is compromised, but BEFORE it is known to be compromised.  Note that passwords do not rust or wear out in any gradual sense.  They are either compromised or not compromised.
  - If you age the password before it is compromised, your defense is not strengthened.  It is as likely to change the password INTO one that will be guessed as it is likely to change it away from what will be guessed.
  - If you know, or suspect, the password is compromised, you should change the password immediately.  This is not aging, it is reaction to a specific successful attack (which could include simply a lost laptop).  
Of course, successful use of aging depends on the ability to prevent the attacker from acquiring the new password.  Keyboard loggers make aging irrelevant.  And many people change passwords in minor ways (incrementing  one digit), which makes a guess based on a previous password fairly easy.

If you do choose to age a password:
  1. Make sure the period is short enough.  If you force a change every 90 days, that means a successful attacker has access to the account for an average of 45 days.  For some accounts this is way too long; for others it may be acceptable.  (Of course, that means you think the damage done in 45 days would be a lot less than the damage done in, say, 180 days.  That would depend on what the account exposes.  In some cases, all the damage would or could be done in 1 day.)
  2. Make sure the new password is substantially different from the old one. 

My personal view is that accounts whose compromise could cause extensive damage, either for surveillance or with admin privileges, should be protected with two-factor, as Jack mentioned.  Aging probably cannot be short enough to mitigate the risk.  But if the only option you have is aging, use it with a short period.

For other accounts, which are often compromised to exploit for sending spam or for attacking others, the compromise does not stay secret very long.   The chance is small that an aged password just happens to come in between the compromise and the spamming.  In this case aging is unlikely to help at all, and should be avoided.

Once the aging period is long, it simply becomes ineffective at anything other than annoying users.

In this NIST Draft:

There is the following on page ES-2:

"Changing passwords periodically also slightly reduces the risk posed by cracking." 

They go on to discuss in more detail, but I think the word "slightly" is pertinent.  Make sure the slight improvement in security is worth the cost to you and your users.


Bob  Goldstein


Robert Goldstein
Director
Office of Information Technology
Pitzer College
1050 N Mills Ave.
Claremont CA 91711


From: Jack Suess <jack@UMBC.EDU>
Reply-To: EDUCAUSE Listserv <CIO@LISTSERV.EDUCAUSE.EDU>
Date: Thursday, October 24, 2013 9:37 AM
To: EDUCAUSE Listserv <CIO@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [CIO] Passwords: To Age or not to Age?

Valerie is right to point out this resource. 

One of the things we did at UMBC is work with our auditors to educate them on the NIST 800 standards. NIST is chartered by the federal government to develop best practice for the government and they have a rigorous and scientific validated approach (peer reviewed) to the work they do. Whereas auditors could say best practice was "N" days there is in fact no backup to that and if you take that to the logical conclusion the limit should "0" and we all use a set of one-time passwords :-)

The NIST 800-63 standard was revised as 800-63-2 and here is a draft, http://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf

If you go to page 102 in the actual NIST publication (Appendix A) they walk you through calculating password strength using their methodology.

What is very helpful, though a bit technical, is looking at one of the early password entropy calculators that NIST developed -- http://bit.ly/HhkbVk

The calculators let you evaluate the benefit of different rules -- how much strength do you gain by going from 90 to 180 (not much) versus increasing the complexity or length.  We used this to develop our password policies. We had an unbiased tool that could show the auditors that our passwords rules were stronger than their rules, even though the change limit was longer due to compensating controls such as restrictions on the letter combinations and length that were more rigorous.  

Using NIST, conceivably we could go many years before we force a password change.  We track failed password attempts and we force passwords to be changed when they meet a value we feel is to great for that users risk level. In this way we can have different rules for students, faculty, and staff based upon risk to the institution. Saying that, we do try to force password changes every two years.

We are in the process of transitioning to multi-factor for higher risk users (mostly staff in IT, power users, others with higher risks) and this will help eliminate some of the issues with passwords for power users.  If you are interested in multi-factor, look at this IAMonline, http://internet2.adobeconnect.com/p9pjt3ncks9/  that took place in September 2013.

jack


Jack Suess             UMBC VP of IT & CIO
jack@umbc.edu     1000 Hilltop Circle
410.455.2582          Baltimore Md, 21250
Homepage:             http://bit.ly/fSB5ID



Close
Close


EDUCAUSE Connect
View dates and locations

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

EDUCAUSE Institute
Leadership/Management Programs
Explore More

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.