How to Implement NIST 800-63B Changes (as Painlessly as Possible)
As many of you are aware, the NIST Special Publication 800-63B is a draft guideline on best practices for digital identity. While NIST setting national guidelines on securing technology is nothing new, this particular chapter on authentication and lifecycle management has proven to be a game-changer in the world of online passwords since its release last year.
While the guideline is still in draft form and not officially published, organizations around the world are nevertheless changing up their security policies to align with its requirements. However, this can be a daunting task- with enterprises often needing to make significant changes to achieve compliance.
Summary of Changes
Let’s briefly review the major changes in the 800-63B standard compared to previous guidelines. The birds-eye view is that passwords should be easier and more intuitive rather than secured through arbitrary complexity requirements. Here’s a quick rundown of the specific changes:
- Maximum length increased to 64 characters or more
- All printable characters allowed, including spaces
- Fewer complexity rules enforced (“Must include one uppercase/number/symbol/etc.”)
- Expiration of passwords no longer based on a time schedule
- SMS as a two-factor authentication method removed
- Passwords should be compared to dictionaries and lists of common, easily-guessed passwords
This is a significant departure from the old rules of using rigorous complexity requirements and frequent expiration, but one that actually factors in human behavior. Security experts have known for a long time that strict rules are counter-productive, because users negate the security of these complexity rules. For example, they might write down their complicated passwords on sticky notes to avoid forgetting them, which is arguably worse than have a slightly-less than complex password that is not written down anywhere.
Now that we’ve gone over the major changes, here are a few ways that your organization can implement the guidelines of NIST 800-63B with as few hiccups as possible.
Obtain Support from Senior Management
As with any significant change to the security program, you must have buy-in from senior management. This ensures that you are acting with the permission and authority of the executive team and that users can’t go over your head to get around these changes. Prior to implementing any changes or even meeting with your staff to discuss implementation, meet with the senior leadership team to outline the changes and benefits that this solution will provide. Only after getting management’s approval should you approach your technical teams to discuss changing password policies.
Ensure Your Enterprise Applications are Compatible
You won’t get far if your systems and applications don’t allow users to create passwords that line up with NIST recommendations. Legacy software will be especially difficult to work with, as most older platforms don’t allow passwords longer than 8-10 characters. If one of your applications poses problems, consider reaching out to the vendor to see about implementing a custom password policy for your organization so that you can align with NIST requirements. If a custom policy is not an option, you might want to consider making an exception for that application or moving away from that software.
Consider Single-Sign On for Security and Better User Experience
Single- Sign On (SSO) has gained huge traction in recent years as an easier and more secure authentication solution. If your web applications support SSO but you just haven’t taken advantage of it yet, consider implementing a tie-in to your domain credentials to streamline the authentication process. This will greatly reduce the amount of passwords your users have to remember, and will move them away from the vendor’s password policy which is often weaker than yours. Most software vendors have noticed the increasing demand for single sign-on, and are usually happy to hook into your LDAP – just be sure you’re using SAML 2.0, of course! This way, you’ll only have to change the security policy on your local Active Directory instead of scrambling to make sure you covered all of your disjointed application-specific policies.
Create Comprehensive and Thorough User Education/Awareness Programs
After getting management’s support and making sure these changes would work in the first place, the most important step is to bring awareness and education to your users. Communicate this change well in advance of the implementation date, and send out regular reminders as that date approaches. User education programs should highlight these important points without getting too technical:
- Passphrases are now an option: longer and easier is better than shorter and more complex.
- You won’t have to change your password unless you suspect a security incident has happened. (NIST’s logic presumably being that if a user takes time to create a secure password and if there’s no suspicion of risk, they should not have to go through the trouble of thinking of another one.)
- If you’ve been using an incremental numbering scheme after every expiration (e.g., password1, password2, password3), you should change it to something totally different.
- If the organization uses SMS for two-factor authentication, they will have to find an alternative method of two-factor authentication.
Above all, present this change as a win-win for them and for the organization. Everyone gets passwords that are easier to manage, and the business benefits from increased security.
Roll Out Changes in Batches
When it comes time to pull the trigger, don’t force the change on the entire organization overnight. Your help desk will get flooded with calls, and your users will think the building is burning down. Instead, separate the company into batches and roll out the change to smaller groups over time. This reduces the strain on your support team and allows most of the business to continue functioning on the “old” rules while you make sure the transition happens smoothly – and in the event that something goes wrong, only a small group will be affected. Be sure to communicate this plan to your users so they understand when their turn is.
After you’ve made all these changes, it’s important to get feedback from your users to understand their experience with the new system. You should monitor your users’ feedback in case there are any pain points specific to your environment. Security is an ongoing process that is made better by giving weight to user concerns and understanding the best method for implementing improvements without disrupting operations.