I've mentioned in previous blogs that BIDMC has contracted for an enterprise wide security assessment to ensure our security projects are aligned with best practices. Over the next few months I'll write several posts about the issues we've reviewed and the evolution of our thinking about security.
Today I'll start with something basic.
What is the right frequency to require passwords changes?
Many security experts and commonly used guidelines suggest a 90 day password expiration frequency.
To understand the common practices of hospitals in Massachusetts, I asked many of my peer CIOs about their password change policies. The answer - some organizations are at 9 months, some are at 6 months, and some are at 3 months. One is at 4.5 months - a compromise between 3 months and 6 months.
Two questions we need to answer before crafting the ideal policy.
1. Does changing passwords frequently actually increase security?
2. What is the impact of frequent password changes on the user experience (especially for smartphone and iPad users)
For question 1 - The benefit of requiring a more frequent change to passwords has been the topic of debate within the IS community for years. While many experts claim shortening the period reduces risk, others argue the opposite because users cannot remember frequently changed passwords and write them on post it notes which they affix to their work area.
Here are three references which suggest that increasing password frequency reduces security.
http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
http://www.healthcare-informatics.com/blogs/dale/password-expiration-insanity
http://digitaltrustllc.com/?p=49
For question 2 - Frequent password changes can be challenging for users of mobile devices. Generally, something like this happens
You change your password via a desktop application
Your iPhone and iPad try to synch email before you can change the password on them
Your account is locked out for 20 minutes
You try to change your password on your mobile devices but you cannot because of the lock out
You call the IS help desk and they remove the account lock but you spent two hours trying to change the password on all your mobile devices before the account is locked again, calling the help desk several times.
I'm sure there is an ideal way to do this i.e. turn off all the cellular and network connections on your mobile devices and change your password via a desktop application. Then, change them on your mobile devices before reimplementing wireless network connections.
Regardless, doing this every few months will increase help desk support call volume and user frustration.
A side effect of creating a suboptimal user experience is that users will stop using tightly controlled corporate applications and instead access consumer grade technology such as Gmail, Dropbox, and text messaging, increasing risk and ultimately reducing security.
As a next step, we'll ask our multi-stakeholer IS Security and Privacy Committee to review the literature (pro and con) about frequent password changes. They'll evaluate the risks and benefits of various password change frequencies and then we'll select a path forward which hopefully balances the risks of infrequent password changes and too frequent password changes.
Just as I asked about remote access, I welcome your comments about your password expiration frequency policies and experience.
In the iPhone/iPad example the 20 minute lock out seems to be a mistake.
ReplyDeleteOn the software side you could simple prevent the lock out from happening the day the password gets changed.
I agree that having to change passwords creates more security risks. I now have so many different passwords that I keep them in a list on my cell phone, behind yet another password.
ReplyDeleteI like the idea of forcing us to use use a randomly generated password and then letting us memorize it and continue using it indefinitely.
For this and other reasons (prevention of DoS attacks for example) you may want to look into a product like LockoutGuard, that integrate with the proxy servers typically used for Exchange ActiveSync to do only a "soft" lockout specific to the mail service after repeated failed logins. That way issues with a mobile device do not affect a user's desktop experience.
ReplyDeleteOne of the issues with any password is that if it stays the same for a suficiently long period of time, then an attacker can brute force the password while not triggering any alerts (2-3 incorrect tries per day.) Thus the restricted time frame for a password.
ReplyDeleteThis however seems to be using a different metric than we are concerned about. We are worried about someone finding the password through putting in attempts. One option I've heard, is to have the password time out after a set number of incorrect login attempts. Thus if someone is trying to gain access through trying passwords, it will be found (hoepfully by the system monitoring itself, but also by the user complaining that they need to change their password again.)
If you set the number of incorrect attempts to .01% of the number of passwords possible, then you have a very small chance that someone could brute force the password (and this should be both a smaller, and more measurable percentage, than the X day reset password system.)
Thanks for the posts!
We have to ask ourselves what exactly we're trying to prevent. If we want to make a "found" password - shoulder-surfed, discovered on a post-it, etc. - not useful then we need to change passwords everyday. If we want to prevent brute-force attack - assuming someone is getting our hashes, which is odd - then we need to keep the expiry under the time it would take to do the math given our organization's password complexity policy. I can't think of any other scenario where password rotation is useful.
ReplyDeleteOur password policy expires passwords after 180 days, forcing the user to create a new password that has not been used in the past five resets. Is that too long?
ReplyDeleteIt's all about entropy really. Passwords by themselves just aren't that good at protecting a determined attacker from compromising your account. It's not at all difficult to crack a password with little to no complextivy using tools like mimikatz, Cain, John, and rainbow tables. There are even password dictionaries generated using pwgen that provide over 44 million random passwords that have a 21% hit rate, so the approach recommended earlier doesn't really offer any additional benefit.
We have been encouraging our users to create passphrases that are at least 15 characters in length. Dictionary attacks will fail against this type of password, especially when random words are combined (i.e., "play ant smart bone"). I've been unable to crack that passphrase with any of the rainbow tables I'm currently using, and with over 99 bits of entropy a brute force attack would take longer than the life expectancy of the user. Of course it's all a moot point when a tool like mimikatz can read the clear text password directly from memory, but that's a different risk.
So, for now anyway, I'm comfortable with our 180 day password lifespan. In fact, if our password audits turn up passwords that beat our password dictionaries, rainbow tables, and brute force attempts then I'm inclined to exempt them from our password expiry rule for up to 18 months for that user. If we had full-blown two-factor authentication in place (on-site and remote access) I'd probably be ok with doing away with password expirations altogether.
All my passwords are randomly generated strings varying in length from 11-32 chars (alpha, digit, and symbols) and stored behind another password like one of the other posters. But having to change such passwords (which are impossible to crack using dictionary attacks since they are not dictionary words by any stretch of the imagination) is a major pain, especially on handheld devices, and actually decreases the security, since I have to email the password to my device to copy-paste into the form. A good expiration frequency should take into account the length of the password and its "simplicity", so passwords like "changeme" or "1234" should have to be changed every week and random strings such as mine should never have to be changed.
ReplyDeleteFirst of all I am assuming that every hospital has Single Sign-on, which I regard as an imperative to facilitate user satisfaction.
ReplyDeleteIn my opinion frequent password changes are counterproductive.
I see older docs walking around with a pocket organizer that they pull out to determine what password to use in which hospital.
Like HIE we really need to also a system by which a user can synchronize there passwords between locations on a schedule they prefer but somewhat constrained; e.g. 1 year max between changes. However, I recognize that this is still blue-sky wishful thinking.
In general less frequent changes with requirements that require strong password structure are a preferable approach.
In addition to this, a ‘how-to’ cookbook should be published for the user to help them coordinate the synching with mobile devices.
Example:
1. Turn off your mobile devices’ Wi-Fi
2. Turn off you mobile devices’ wireless (Airplane mode)
3. Log into your hospital account on a computer and change the password to a new one
4. Change your password registry on your mobile devices to the new password
5. Turn on your mobile devices’ Wi-Fi
6. Turn on you mobile devices’ wireless (disable Airplane mode)
While not disclosing whether or not I impose password changes, if I were to impose changes then I would consider a predictable recurring frequency for password changes (e.g., 3 months, 12 months, etc.) to be a security risk, therefore I would use a random and unpredictable frequency for password changes, if I were to impose changes, which I neither confirm nor deny...
ReplyDeleteI made an agreement with our research community of users. You move to a complex pass phrase of >15 characters, and I will never ask you to change your password again.
ReplyDeleteAs others mentioned - password entropy isn't affected by frequency of changes. Changing the password only restores protection after the password has been cracked. So changes are really only there to make sure that already-found-holes are systematically plugged on a no-later-than basis. This change did uncover at least one scenario where we could improve our off-boarding process to address security when a contractor left the organization.
The biggest challenge in this move has been the inconsistent support many software packages have in password support - more than a few older packages have limits of 10 or 12 characters, preventing full adoption of pass phrases. Which means so software-level policies still have to be maintained.
In addition to the change above, we have also movied aggressively to device-based digital certificates, which provide a significant degree of additional protection against hacking.