
New NIST password guidelines: don't require character types or rotation - aaronharnly
https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-verifiers
======
aaronharnly
Operative bit in 5.2.2: "Verifiers SHOULD NOT impose other composition rules
(mixtures of different character types, for example) on memorized secrets.
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily
(e.g., periodically) unless there is evidence of compromise of the
authenticator or a subscriber requests a change."

I'm cautiously hopeful that this will supply needed ammunition for those
advocating for saner password rules and policies in organizations big and
small.

~~~
logicallee
They should settle on requiring a memorable, yet high entropy password that is
impossible to conpromise. For example the string
"IpromiseIamauthorizedtoaccessthissystem". This string is very high-entropy
(does not appear anywhere in Google, is 9 words, a mixture of upper and
lowercase. For someone trying every character combination, it would take over
a thousand years to crack. It includes a second factor (the promise) by
definition. In short it should be the REQUIRED secure password for all
applications.

~~~
criddell
Bruce Schneier disagrees with you:

[https://www.schneier.com/blog/archives/2014/03/choosing_secu...](https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html)

The main point from his essay is anything that can be remembered can be
hacked. He then softens that statement to show a way to take your memorable
phrase and turn it into something stronger.

~~~
Tomte
Schneier is simply wrong there.

He wanted to rant and therefore didn't read the description of the "xkcd
scheme" with enough concentration to understand it.

Legions of security people debunked Schneier, but unfortunately he didn't have
it in him to retract his claim and update his post.

This blog post is the best example you can give of Schneier quitting academic
discourse and becoming a pundit.

~~~
criddell
Can you point to a good debunking?

~~~
PwdRsch
Here you go: [https://security.stackexchange.com/questions/62832/is-the-
of...](https://security.stackexchange.com/questions/62832/is-the-oft-cited-
xkcd-scheme-no-longer-good-advice)

~~~
criddell
After reading through most of that, it seems that the big problem with the
XKCD scheme is that it's often impractical. Too many sites restrict password
length and so you are forced to use the Schneier modification to get more
entropy per character.

If you make a password from an alphabet of 64 characters (upper and lower
case, digits, and some special characters), there are 6 bits per character of
entropy so a ten character random password could have 60 bits of entropy.

If you are choosing words from a list 4000 words long, there are 11 bits of
entropy per word and so you would need to string together five random words to
get a password of equal strength. The big problem then is having enough space
to type that many characters.

~~~
PwdRsch
Yep, unfortunately for passphrases the maximum acceptable password length on
web sites tends to be the #1 factor limiting their use. I created sample
passphrases and tried them on a handful of different sites to measure the
problem. See starting slide 31 in this presentation (PDF):
[http://www.passwordresearch.com/files/How%20Secure%20Are%20M...](http://www.passwordresearch.com/files/How%20Secure%20Are%20Multi-
Word%20Random%20Passphrases%202.01%20-%20ISSA.pdf)

~~~
criddell
Do you know why sites would set a low limit? I can understand limiting to,
say, a couple hundred characters, but 16 is ridiculous. These days, all
anybody is going to store is a salted hash so the passphrase length should be
mostly irrelevant.

Edit: that's a pretty nice slide deck. Thanks for the pointer.

~~~
dragonwriter
> These days, all anybody is going to store is a salted hash so the passphrase
> length should be mostly irrelevant.

Since I still run into services where the "forgot password" mechanism emails
your current password in the clear, this is unfortunately not as true as one
would hope.

------
bdamm
This part is very good advice:

    
    
      When processing requests to establish and change memorized 
      secrets, verifiers SHALL compare the prospective secrets 
      against a list of known commonly-used, expected, and/or 
      compromised values.
    

So, no rotation, no character set rules, but the password better not be
already known. They specifically refer to comparing against a corpus of known
broken passwords. Very good.

~~~
thaumaturgy
I wrote a tool a while back that's excellent at this. It produces a 1MB file
that you can do a straightforward search against and use to blacklist 161,000
different common passwords.

[https://github.com/robsheldon/bad-passwords-
index](https://github.com/robsheldon/bad-passwords-index)

I want people to use it. I gave it the most permissible possible license.
Please people, use it. I'll even update it Real Soon Now.

~~~
Hondor
I like your license choice. Is there a reason you chose Unlicense over CC0?
I've never heard of it before. The text is a bit shorter than CC0 which is
nice. Creative Commons recommends against using CC licenses for software so as
not to step on the toes of the GPL which doesn't seem applicable if you really
want public domain. [1]

[1] [https://creativecommons.org/2011/04/15/using-cc0-for-
public-...](https://creativecommons.org/2011/04/15/using-cc0-for-public-
domain-software/)

~~~
thaumaturgy
Oof. I don't remember exactly, but I do remember spending a lot of time (too
much time) deciding between various license options. I _think_ in the end I
chose Unlicense primarily because it's easier to find Unlicensed projects on
Github.

------
Angostura
This bit caught my attention:

>Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint”
that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT
prompt subscribers to use specific types of information (e.g., “What was the
name of your first pet?”) when choosing memorized secrets.

I wonder if Mastercard and Visa will reconsider this policy.

~~~
pwg
Wait? You mean you answer those questions with real data?

My answers to those (when required) always look like this:

> “What was the name of your first pet?” JBK?a0ly(VE3E-|-@BADZFPS<1Fh$X23

Where the "goop" is generated, and remembered, by my password manager
([https://github.com/zdia/gorilla/wiki](https://github.com/zdia/gorilla/wiki)).

~~~
detaro
You really think if I call in trying to impersonate you and that question
comes up the customer service person is going to require me to recite that and
not accept "Oh, I just put some random garbage in" as a solution? Something
that seems like a realistic answer, but is totally wrong is likely a better
choice.

~~~
vidarh
I routinely get into my own accounts by saying "oh, I don't remember wat I set
that to" for multiple security questions until I get questions I don't need to
look up the answers to.

It really is scary, in that even my bank will fall back on things that are
either easy to obtain or easy to guess, because they clarly have to deal with
too many people who either genuinely have no clue, or like me can't be
bothered to look up what I've answered. "Telephone banking password? I have no
idea what that is. Did I set one? Sorry, can't remember..."

------
hug
Previous related discussion around these rules here:
[https://news.ycombinator.com/item?id=13016948](https://news.ycombinator.com/item?id=13016948)

------
SeanDav
> _" When processing requests to establish and change memorized secrets,
> verifiers SHALL compare the prospective secrets against a list of known
> commonly-used, expected, and/or compromised values."_

This has to be applied to the whole password (which it implies anyway) or you
end up with the rather silly situation which I encountered the other day when
I had to create a temporary password for a Microsoft service. It absolutely
refused to accept even a very secure password if there was a portion that was
not secure.

For example: a password similar to "$4(password(!monsT3rDiet%@" was rejected.
But if I removed the word "password" and made the string shorter (and
therefore less secure), that was okay!

------
labster
"If Unicode characters are accepted in memorized secrets, the verifier SHOULD
apply the Normalization Process for Stabilized Strings defined in Section 12.1
of Unicode Standard Annex 15 [UAX 15] using either the NFKC or NFKD
normalization."

I had not even thought about normalization before in this context, but I could
see it being an issue if a user moves to a new device. But what if new
composed characters are added to Unicode, does that mean the user can no
longer log in with NFC passwords? I guess that K in NFKC is important.

~~~
lmm
NFC decomposes composed characters that were not present in the first version
of Unicode, for precisely this reason.

------
peterjlee
I'm not sure if accepting unicode characters is a good idea. It would make it
more secure but you can very easily get locked out of your own account if you
try to login from another device without the correct input method.

Here's one extreme example of it: "I included emoji in my password and now I
can't log in to my Account on
Yosemite"([https://news.ycombinator.com/item?id=10742351](https://news.ycombinator.com/item?id=10742351))

~~~
tuwtuwtuw
A somewhat similar issue appears with Bitlocker in Windows. When you set your
password you are using your custom Windows keyboard layout, such as sv-SE
(Swedish). But then when you are prompted to enter your password during boot
to decrypt your computer the keyboard is always en-US.

It's fun figuring out how to type Swedish and special characters on a foreign
keyboard layout. Of course no part of the UI indicates this layout issue.

I think Unicode is good. I think companies should fix their broken input
instead.

~~~
loup-vaillant
Shame on Microsoft, then. My Ubuntu Linux laptop was installed with the
default settings for full disk encryption, and it uses my favourite layout
right there at boot time.

~~~
nikcub
A BIOS is 7bit ASCII - if you want anything more than that you need to load a
ramdisk with drivers. If you're loading a ramdisk with drivers then you may as
well also load a keylogger.

You'd also need to recreate that ramdisk if your hardware fails, and good luck
booting from non-root encrypted volumes.

Using EN-US for boot disk volumes is pretty good advice.

Microsoft have thought this through - their recovery keys are ASCII numerals
only and are entered using _function keys_ since they're the only universal
keys.

edit: relevent Technet: [https://technet.microsoft.com/en-
us/library/ee449438(v=ws.10...](https://technet.microsoft.com/en-
us/library/ee449438\(v=ws.10\).aspx#BKMK_Key)

~~~
loup-vaillant
And where exactly the keylogger is supposed to come from? Has your laptop been
tampered with during lunch? Then I'm afraid bitlocker is just as screwed as my
Ubuntu. Or has the laptop been owned during use (remote vulnerability, double
click on a malware…)? Same thing.

I'm not sure I see the point of this limitation. At a first glance, it seems
using the BIOS only doesn't buy us much.

~~~
user5994461
May I suggest a hardware keylogger?

Noone will ever figure out that the fat plug at the end of the USB cable is a
keylogger =)

~~~
DanielLee5
Any recommendations on a good keylogger software please? Have anybody tried
this one [https://www.refog.com/](https://www.refog.com/) , I read only
positive reviews on it. Thanks in advance.

------
TwoBit
I never understood thecidea of having to change my password periodically. The
password was good last month, why isn't it good now?

~~~
alcari
The rationale was that if, password hashes got compromised, the attacker would
only have until the next forced rotation to crack the passwords and take over
accounts.

edit: or, in particularly terrible systems, if plaintext passwords were
leaked.

Of course, that's only useful if it doesn't affect any other password security
concerns, and it turns out that users who are forced to change their passwords
frequently pick worse passwords, which is a bigger problem than the scenario
this was supposed to protect against.

~~~
function_seven
> it turns out that users who are forced to change their passwords frequently
> pick worse passwords

I can vouch for this. My rotating password at work is _______1, followed by
_______2, then _______3, and so on. If a year-old hash gets cracked, it won’t
take a rocket scientist to know that the password right now is _______4.

~~~
zie
Get a password manager already, and let it just generate random passwords for
you. Typing in passwords is so lame. :) If you are on macOS I highly recommend
[https://github.com/ravenac95/sudolikeaboss](https://github.com/ravenac95/sudolikeaboss)
(and by extension 1Password).

~~~
Tactic
This would be fantastic if work allowed me to install one. Sadly, some of us
work in locked down environments so resort to such silliness to get through
the work day.

~~~
zie
I'm sorry. that sucks. That's just stupid. I could see employers requiring you
to use their password manager, but ugh, not allowing use of one is just gross.

That said, lastpass can work without any modifications to your local
machine(i.e. it can work without any browser plugins even) tho it's not very
fabulously integrated, it does work... Assuming of course they don't block
access to the lastpass website and JS.

~~~
function_seven
Does it work to allow me to log in to my machine or to unlock it? (Serious
question. If so, then I will happily use a 16 character blob of entropy)

------
cmurf
"Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment)
or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6
characters..."

Does this include credit/debit card PINs?

"Verifiers also SHALL NOT prompt subscribers to use specific types of
information (e.g., “What was the name of your first pet?”) when choosing
memorized secrets."

I take it this proscription applies to the actual passphrase, not as part of
an account reset mechanism? If so, that's too bad, I really don't like these
questions let alone the storage of the answer. Are these answers secrets
though? If so, send like it's proscribed, and also they have to be salted and
hashed in which case the answer itself isn't being stored.

------
discreditable
They also discourage biometric use:
[https://pages.nist.gov/800-63-3/sp800-63b.html#biometric_use](https://pages.nist.gov/800-63-3/sp800-63b.html#biometric_use)

------
rconti
Super relevant because today I got the annual reminder to check my Social
Security statement online.

Go to login, password expired. Expires every 6mo. Also, requires punctuation.
I type in a typical strong/long password and it says "weak" until I append !
to the end and magically now it's "STRONG!"

------
guelo
At my publicly traded company I was told that they have to do password
rotation because of Sarbanes Oxley. Is there any truth to that?

~~~
dragonwriter
I'm less specifically familiar with SarbOx details than HIPAA, but I suspect
the former, like the latter, requires sexurity processes that address
particular issues and your institution has adopted procedures (possibly from a
third-party canned set) to satisfy those that require rotation. A lot of
"required by HIPAA" mythology has this origin, and what I understand of SarbOx
is that it's generally similar in this regard.

~~~
witty_username
> sexurity

Typo?

~~~
vidarh
Some security processes _do_ feel a bit like bdsm.

------
OliverJones
It says "SHALL be generated using an approved random bit generator." What are
some examples? debian /dev/urandom? dotnet RNGCryptoServiceProvider? others?

Who approves this stuff? Does anybody know?

~~~
SparkyMcUnicorn
Edit: Confirmed info here

[http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP...](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf)

Source: [https://www.nist.gov/news-events/events/2016/05/random-
bit-g...](https://www.nist.gov/news-events/events/2016/05/random-bit-
generation-workshop-2016)

------
ht85
Good to see that after all this time dodging corporate pressure to implement
counter-productive measures, the guidelines themselves have changed for the
best :)

------
torbjorn
>Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well. So, can
passwords contain emojis under these guidelines?

~~~
theandrewbailey
Yes. The larger the character space, the better. In fact, even today, I'm
astounded by services that let me set passwords with "high" ASCII characters,
like íÑVTx¾]õ^ÖcÉ^x½0ÞØý½

------
rphlx
They appear to be dangerously unaware of modern memory-hard PBKDFs such as
Argon2, winner of the
[https://en.wikipedia.org/wiki/Password_Hashing_Competition](https://en.wikipedia.org/wiki/Password_Hashing_Competition)

------
Tostino
Interestingly enough, I just recently released a password strength library
which can help enforce these exact requirements.
[https://github.com/GoSimpleLLC/nbvcxz](https://github.com/GoSimpleLLC/nbvcxz)

------
protonfish
Wait, 10,000 iterations of the has function? That's surprising, and of
questionable value.

~~~
alltakendamned
Yes, at least. _and_ in combination with a slow hashing function such as
PBKDF-2, where the current recommendation for server side hashing is 100K+
iterations.

The workload is ideally set to something that is acceptable to users, but
considerably slows down brute-force attempts by attackers.

Please educate yourself some more before making statements on the value of
things that surprise you, they might be there for a good reason.

~~~
protonfish
The brute force would have to be on a raw database dump, and is probably in no
rush to complete. Also, speed being hardware dependent, the attacker could
simply get more, or wait for the advance of Moore's law so that what was
"slow" last year is now fast. Deliberately slow hashing is just shouting into
the wind.

Your comment about "please educate yourself" was not constructive.

~~~
taco_emoji
You don't seem to understand the scale here. Normal, non-secure hash functions
can be calculated at a rate of hundreds of millions per second, and can easily
be brute-forced within a few hours. Current rule of thumb for PBKDF2 (for
example) is to choose an iteration count corresponding to around _two_ hashes
per second, and the work is not parallelizable. That turns those hours of work
into _millenia_.

If it really concerns you, proper practice is to store the iteration count
alongside the hash and salt, so you can easily go through and add more
iterations if you want as computers get faster.

------
Dylan16807
That code points are counted as a single character is absolutely mandatory,
but there's no requirement to allow passwords over 6 characters? Interesting
choices.

------
stefek99
5.1.1.2. Memorized Secret Verifiers

I prefer plain English aka "passwords"

~~~
lemtzas
I like the implications of "pass phrase"

------
vog
Obligatory XKCD on this topic:

"Password Strength"

[https://xkcd.com/936/](https://xkcd.com/936/)

------
kutkloon7
Finally some common sense in guidelines (appearently, some people need
guidelines for this stuff because they have no common sense).

------
nicois
pwgen

------
known
[https://www.random.org/passwords/?num=4&len=8&format=html&rn...](https://www.random.org/passwords/?num=4&len=8&format=html&rnd=new)
FTW

~~~
dimino
I prefer the passphrase: [https://xkcd.com/936/](https://xkcd.com/936/)

Also, I feel _very_ funny using generated password from a website. If I need a
new password, I can just generate one in Python or something.

~~~
e12e
I have this macro saved in ipython. Note that I use a subset of symbols that's
easy to type on most(?) keyboard layouts withoutany gymnastics:

    
    
      %load pwm
      import random as r
      import string as s
      def pw(n=12):
        return "".join([r.choice(
                           s.ascii_letters \
                          + s.digits \
                          + "|!@#$%&/()=?+\-_.,;:")
                         for x in range(n)])

~~~
apk17
ruby -e 'rand(34*10).to_s(34)'

I prefer not to have to use the shift key in passwords, and the 34 instead of
36 ([0-9a-z]) solves my german/us layout problem in a very golfy way.

~~~
dchest
Both your and parent's password generators are not secure: they use non-
cryptographic random number generators, which have limited entropy.

~~~
vidarh
That matters very little if you are manually generating an occasional password
here and there for personal and an attacker have no reason to know your
specific method of generating the password.

~~~
e12e
True. Otoh I just told the attacker my specific method :-) And I'd prefer a
system that was secure enough that doing so wasn't a problem.

