Re: NIST SP 800-63B and Passwords

[Emery Rudolph <erudolph () UMD EDU>]

Good day everyone,

Please note that my comments do not reflect those of my institutions
security office, but are instead my own.

I trust that many institutions follow NIST guidelines and rely on them for
both general and specific guidance. I would still caution you to make your
analysis based on multiple sources. The rationale that was noted within the
NIST document referred to the need to memorize complex passwords resulting
in poor behavior, such as writing or storing in an unsafe manner. To combat
this behavior, the recommendation is to relax the complexity to allow the
passwords to be more easily memorized.

This may hold true for users who only have 2-3 accounts to remember, but
the reality is most people today have tens-hundreds of accounts. This means
that even if you relax requirements, people will more than likely use the
same password or iterate it by a digit. And the more accounts users have,
it becomes inevitable that they will need to document their passwords
regarless. Additionally, logic dictates that limiting password complexity
severely decreases the attack vector requirements from bad actors, since
they can now effectively eliminate an entire set of characters from
candidate attacks. This becomes a more critical point when you consider
that more attacks are coming from automated mechanisms using much more
robust computing nodes. Without complexity involving special characters
(including non-traditional ASCII), passwords will revert to standard or
compound dictionary words, which are easily cracked. I would hope that we
recognize this as a step backward.

I think that it is a good recommendation to use a common and regularly
updated blacklist to challenge for weak passwords, but the recommendation
to not periodically expire passwords is not good practice, because it does
not take into account that password stores are handled or accessed by
multiple people and code, thus there is always the possibility that such
stores will be unintentionally (or intentionally) compromised.
Changing/expiring passwords in a manner that is not inappropriately
burdensome on the user community is a reasonable mitigation policy.

I believe that instead of focusing on relaxing complexity, standards
organizations should continue to investigate, strategize and promote
standards and recommendations for encrypted password stores. Ultimately,
providing users with a way to efficiently and safely store passwords is the
true answer to most complexity issues.

In summary, I like the fact that we are constantly investigating policy and
evolving thought around technology, but I think that we have come to our
current position on password security through decades of study and
experience and any drastic changes that have the potential to circumvent
security should be undertaken with extreme caution.


----------------
Very Best Regards,


*Emery Rudolph*
*Director, PDAA*
*Division of Information Technology*


*University of Maryland(301) 405-9379*


On Mon, Jul 31, 2017 at 8:11 PM, Miguel Hernandez <
miguel.hernandez () domail maricopa edu> wrote:

> Colleagues,
>
> A question about the latest version of NIST SP 800-63B (Authentication and
> Lifecycle Management) (https://doi.org/10.6028/NIST.SP.800-63b).
>
> Since its release in June, not a week has gone by without a handful of IT
> folks stopping by and asking when we are going to (1) disable all password
> complexity requirements and (2) stop requiring periodic password changes.
>
> As I’ve reviewed the NIST publication I note the two recommendations
> quoted below which has fueled the above questions:
>
> “Verifiers SHOULD NOT impose other composition rules (e.g., requiring
> mixtures of different character types or prohibiting consecutively repeated
> characters) for memorized secrets.”
>
> “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily
> (e.g., periodically).“
>
> So my question is: Do any of you have a sense of urgency to disable your
> password complexity checks and disable password expiration?  Is this
> something you plan to implement over time?  Will you create some relaxed
> version of your current password rules (for example, maybe require at least
> upper and lower case, and extend password expiration to 1 year).  Or will
> you just continue with business as usual and make no changes.
>
> The use of the word “SHOULD” is of course non-mandatory language and is
> only a recommendation.  There are some though who think these
> recommendations are actually requirements and must be implemented
> immediately.  I’d just like to get an idea of what my fellow higher-ed
> institutions are doing.
>
> [image: eSig Logo]
> Miguel Hernandez IV, Ph.D. CISSP, CISA
> Associate Vice Chancellor ITS
> Chief Information Security Officer
> 2411 West 14th Street, Tempe AZ 85281
> email | miguel.hernandez () domail maricopa edu
> website | https://www.maricopa.edu
> *Follow me on Twitter <https://twitter.com/mh4phd>.*
>
> This message contains information which may be confidential and/or
> privileged. If you are not the intended recipient of this message, please
> notify the sender, delete and do not use or disseminate this information.