“This post is part three of our reaction to new recommendations in the National Institute of Standards’ Digital Identity Guidelines (NIST Special Publication 800-63), Appendix A – Strength of Memorized Secrets. You can check out Part 2 here.”
In the Great Password debate that has been generated by the latest NIST guidelines, we (the trainers and experts on the CyberVista team) find we agree with some recommendations and disagree with others. In our previous post, Josh discussed the way password complexity has been found less secure than longer passwords made up of simple words. In this post, we (Robin Abernathy, Ann Lang, and Troy McMillan) want to discuss NIST’s new guidelines for password resets (password age) and responding to password failure/account lockout (failed authentication).
Among the otherwise sound advice in the Digital Identity Guidelines (NIST SP 800-63B), we did pick out three points that cause us some consternation:
- Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. (Section 5.1.1.2)
- Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100. (Section 5.2.2)
- When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address. (Section 5.2.2)
Love it a long time, or leave it every 30-60 days?
How many of you out there work for a company that requires you to change your password at a regular interval, usually every 60 or 90 days? Bullet point 1 states that this is no longer necessary.
Troy says: I disagree with this recommendation. I contend that changing the password at regular intervals DOES increase security because it shortens the amount of time it is available for disclosure. The logic behind this new NIST rule is based a failure of how people implement it, not a failure of the concept of password age. In other words, the concept fails because the users do not use unique or secure passwords. They usually choose a new password that’s similar to the previous passwords with a few character changes. This issue would be resolved with proper security awareness training and policy enforcement. Also, there are solutions out there that can prevent users from creating a password that is too close to a previous password. So while we understand what NIST is trying to do with this change, I personally don’t agree with it.
Ann says: I disagree somewhat. The theory is that if you’re ALSO making people choose much longer, easier-to-remember character strings for passwords, like IlikebigpasswordsandIcannotlie! Twoyears beforeI changeit lala hooray!, then you still have the advantage of the password being much, much harder to crack or guess from a mathematical standpoint. After reading through their breakdown of Authenticator Assurance Levels (AAL), I’d be okay following their password age recommendations for any site that’s operating at AAL2 or above.
(For what it’s worth, Microsoft’s 2016 Password Guidance for IT Administrators both counsels you to lose the mandatory periodic password reset, AND to educate users on choosing appropriate passwords and banning commonly used passwords.)
But WHOSE domain and whose site is guarding the authentication? I think the real risk in this advice is all of these third-party service database breaches from sites that force us to create logins to use their services. It can take months for vendors to disclose that they had a breach, assuming they even discover it at all, and many of these breaches include decrypted or unhashed password fields, or plaintext data exposure. It’s in my best interest to assume that (1) my password will eventually be stolen, so I should (2) make sure any stolen password is old news. So no, I don’t think my login for << clothing.com >> should be left unchanged for long periods.
Robin says: I don’t love the “evidence of compromise” in this statement – that is, kicking out the attacker AFTER he has gotten in. Wouldn’t prevention be better?
If at first you don’t succeed, try 99 more times
The next bullet point is about limiting consecutive failed logins to NO MORE than 100.
Robin says: Again, we disagree, but not because limiting failed logins is a bad idea. It’s just that 100 attempts seems very high to us. Any person with even limited security training understands how password crackers work. So by allowing up to 100 invalid attempts, an organization would be allowing an attacker quite a few tries.
While I kind of like that unsuccessfully logging in from the same IP address should NOT cause lockout to kick in automatically (according to the 2nd bullet point), I also see problems if an attacker has gained access to a trusted resource – in other words, a device that has been used to log in before.
Limiting an account to fewer than 20 consecutive failed logins is probably a better compromise between providing security and understanding that users do often forget passwords or make typos. We just feel that the higher limit is inviting problems.
If you’re going to throttle, throttle all the way
Section 5.2.2 addresses Rate Limiting (Throttling) guidelines for repeated account attempt lockouts. To save you the click, we find nothing to disagree with in the bullet points, which mention you MAY include:
- Requiring the claimant to complete a CAPTCHA
- Including mandatory waits following a failed attempt for variable periods of time that increase as more failed attempts are made
- Accepting only authentication requests from a white list of IP addresses
- Leveraging other risk-based or adaptive authentication techniques
Robin says: I disagree – not with these points, but with the final statement in this section, which says, “When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address.” Does that even address IP spoofing? It is very easy to discover the IP address that is used by a particular host. Once an attacker matches that host up with a particular user account, then spoofing the IP address and having UNLIMITED failed login attempts would be a password cracker’s dream. What a nightmare!
Ann says: When I read this, I think they’re just referring to resetting the password lockout counter to zero following a successful attempt IF the attempts were all made from a single IP address. But I think risk-based authentication challenges should be used as often as possible.
In conclusion
Troy says: regarding the advice to let passwords age, I just don’t think that’s a good idea for the reasons above. But I agree with I’m all in favor of being able to make my password be a passphrase as long as I want. I’ve never been a fan of any restrictions in my life (I don’t like it when they tell me I’m cut off at the bar. I don’t care if I am using the tablecloth as a superhero cape), and I don’t like sloppy websites that limit you to 8-10 characters without spaces or dashes as a password.
Robin says: now, our opinions are just that: opinions! But we hope that by expressing these opinions, we can open a dialog with others out there who have experience in the cybersecurity industry.
-Troy and Robin and Ann
Robin Abernathy and Troy McMillan are authors of CISSP Cert Guide (2nd Edition), published by Pearson IT Certification.
Ann Lang edits stuff.