Pub. 8 2019 Issue 3

19 F A L L | 2019 B A N K B Y T E S Auctioneers & Appraisers delivering successful results to Virginia Banking institutions since 1963 www.countsauction.com  Passwords obtained from previous breach corpuses.  Dictionary words.  Repetitive or sequen- tial characters (e.g. ‘aaaaaa’, ‘1234abcd’).  Con text-specific words, such as the name of the service, the username, and derivatives thereof. • Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). How- ever, verifiers SHALL force a change if there is evidence of compromise of the authenticator. A quick review of the require- ments would probably indicate that the first two items are easy to adopt, assuming they aren’t already in place. After all, most organizations are requiring at least 8 characters, if not more, and have done so for several years. Addition- ally, most Windows login screens do not list a password hint, espe- cially in a business setting. It is the last two items in the list that will create the greatest obstacle to using the updated NIST guidelines in a standard work environment. First, there must be a way to compare the user passwords to a list of known dictionary words, passwords obtained from other breaches, etc. and do so DURING password creation. Doing this requires software that ties into Ac- tive Directory and has configurable policies and word lists. While a specific product will not be recommended here, two commercial offerings that come to mind are nFront Password Filter and An- ixis Password Policy Enforcer . Standard vendor due diligence applies to either of these options, and any others discovered during a Google search. Second, once passwords have been set, they should not be changed UNLESS there is evidence of compromise of the authenticator. The simplest method that comes to mind for most organizations is to periodically dump user password hashes and compare these hashes to large rainbow tables, such as the list of 555 million (yes, million) breached passwords hosted by the haveibeenpwned.com cre- ator, Troy Hunt . This list can, and should, also be used to check new passwords before the change is applied. If an organization is willing to invest the time and money into implementing the last two requirements above, and the changes do not go against any regula- tory guidance by which the organization must abide, then a brave new world of no scheduled password changes, and no password resets, will open up. If not, then the NIST guidelines cannot be adhered to and the same old settings must remain in place. Now, before the happy dance starts and password policies are updated to never require a change or enforce complexity, be aware that 800-63B contains recommendations, indicated by “should” and “should not,” as well as strict requirements, reflected by the use of “shall” and “shall not.”