Re: NIST SP 800-63B and Passwords

[Shady Azzam-Gomez <azzamgs () SUNYSUFFOLK EDU>]

Shady Azzam-Gómez
Vice President for Information Technology & Chief Information Officer
Suffolk County Community College
Office: 631.451.4920
Mobile: 631.806.7150
Azzamgs () SUNYSuffolk edu<mailto:Azzamgs () SUNYSuffolk edu>
On Aug 2, 2017 2:16 PM, Emery Rudolph <erudolph () UMD EDU<mailto:erudolph () UMD EDU>> wrote:
> Mark, I agree. MFA is an excellent technology that should be pervasively used, but because we are still in the 
> transitioning phase of MFA becoming ubiquitous, we should not lose site that password policies are generally aligned 
> on a campus global basis, so once you reset (lower) standards, they will be adopted throughout the campus, resulting 
> in increased exposure of those resources that have not yet moved behind 2-factor.
>
> As an analogy, as bad as the odds are against winning the lottery, the fact is that if you dropped the number 
> selection from 67 to 36, the odds of winning rise significantly. Special characters not only add complexity, but also 
> exponentially decrease the attack vector through the base number of available characters. So the pertinent question 
> (notwithstanding MFA) to me is... is a 12 character password formed from a base of 36 characters (alpha, num) as 
> effective and break resistant as a 12 character password formed from a base of 67 characters (alpha, num, spec). 
> Using the lottery analogy, I think the answer is obviously no.
>
> Put MFA in front of everything and the point is moot, but I do not think as an industry we are close to being there.
>
>
> ----------------
> Very Best Regards,
>
> Emery Rudolph
> Director, PDAA
> Division of Information Technology
> University of Maryland
> (301) 405-9379
>
>
>
> On Tue, Aug 1, 2017 at 2:59 PM, Jones, Mark B <Mark.B.Jones () uth tmc edu<mailto:Mark.B.Jones () uth tmc edu>> wrote:
> > I would agree except that ‘the ground has shifted under our feet’.  It is my opinion that no amount of complexity 
> > makes a password good.  It has become so easy to guess or phish passwords that single factor password authentication 
> > is only appropriate for protecting trivial resources.  Ideally, resources of any consequence should be protected by 
> > MFA.
> >
> >
> >
> > If MFA is not implemented it may be prudent to forge ahead with complexity and expiration, but I believe it is time 
> > to unburden users with respect to complex passwords that frequently expire and shift to widespread use of MFA.
> >
> >
> >
> > “Through 20 years of effort, we’ve successfully trained everyone to use passwords that are hard for humans to 
> > remember, but easy for computers to Guess”  xkcd: Password Strength (https://xkcd.com/936/)
> >
> >
> >
> > From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () 
> > LISTSERV EDUCAUSE EDU>] On Behalf Of Emery Rudolph
> > Sent: Tuesday, August 01, 2017 11:59 AM
> > To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
> > Subject: Re: [SECURITY] NIST SP 800-63B and Passwords
> >
> >
> >
> > 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<mailto: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.
> > >
> > >
> > >
> > > 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<mailto:miguel.hernandez () domail maricopa edu>
> > >
> > > website | https://www.maricopa.edu
> > >
> > > Follow me on Twitter.
> > >
> > >
> > >
> > > 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.