
NIST’s new password rules – what you need to know - cpeterso
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/
======
riskable
The importance of this NIST standard cannot be understated. It has a
requirement that passwords be hashed _with a random salt_! Microsoft Active
Directory _does not use salts_!

I am trying to imagine the consequences to all the businesses and agencies
that must adhere to these standards suddenly coming to the realization that
they must replace their Active Directory installations and what that will mean
for administering all their Windows systems. It's not going to be pretty.

You might be thinking, "but these are just guidelines!" Yes, but actually
there's _loads_ of existing business contracts with wording that states the
business must adhere to all NIST (security) guidelines. Also, you can bet that
once this gets finalized other standards will follow suit.

It will be interesting to see what Microsoft does because salts were expressly
_not_ added to AD because so much functionality cannot work with random salts
in place. They're going to have to break backwards compatibility with a lot of
functionality and many 3rd party products that synchronize with AD. Entirely
new APIs are going to need to be written.

It will also become seriously annoying to create keytabs at large
organizations since only domain admins will have that power once random salts
are in place; making automation very difficult.

~~~
oneeyedpigeon
Do those contracts _really_ require adherence to NIST standards, including
whatever future changes are made to them? I would have thought they'd be
restricted to the guidelines as they are at the time the contract is signed.

~~~
failrate
You typically have to renew every few years for DoD.

------
lucaspiller
Recommending not expiring based on time is probably my favourite. I've worked
at two places where that's been a requirement and my password has always been
a passphrase combined with a sequencial number.

~~~
adrr
PCI compliance requires quarterly rotation of passwords and keys.

~~~
sib
Nothing better than rules based on bad data and security theater.

~~~
sp332
If your password is compromised, it will only work until the next reset.
That's better than having one that works for years.

~~~
rconti
That's true, but I'm having hard time thinking of a use case where a
sustained, hidden compromise is 'worse' than a one-time compromise.

I mean, I guess they could login to your bank every week and transfer out $50
instead of just transferring out all your money on day 1, but... ?

~~~
bsilvereagle
There are quite a few scenarios where a sustained, hidden compromise is an (or
several) order of magnitude worse than a one time obvious compromise.

The first to come to mind is a corporate espionage scenario. Do you want to
know what your competitor is up to today, or do you want access to their
briefings/CAD/code for the next 12 months? Long duration compromises also
allow you to slip data out slowly, so a NAS doesn't show 200GB being
transferred off in a matter of hours, but a slow drip of 100MB a day.

At a personal/home use level, long term access to a bank account allows an
attacker to build up a spending profile, which depending on your habits, could
be used for blackmail.

~~~
bleachedsleet
Anecdotal and only related to your last paragraph, but as a security
researcher I can say that 99% of the time attacks on a personal bank account
are never "long term." Most of time, regardless of skill, hackers get in, cash
out and disappear. It's far more lucrative (and generally safer) to empty the
account than try to blackmail someone based on spending habits.

~~~
dotancohen
I happen to know of a bank exploit in which the attackers compromised one
thousand online accounts, and attacked all them (transferring funds) on the
same day.

Presumably the attackers were worried that after several transfers the bank
would notice and block further access, so they kept a roster of compromised
accounts to attack all at once. I suppose that a password rotation policy
would have helped mitigate damage in this case, though something like fail2ban
or automated IDS would have been better.

------
brownbat
> Knowledge-based authentication (KBA) is out.

All the rules are great, but this one might be my favorite. Every time I faced
a list of KBAs I felt like I was trapped in UCB's comedy sketch:

[https://www.youtube.com/watch?v=tMEjpXJZgIA](https://www.youtube.com/watch?v=tMEjpXJZgIA)

(If a common security device is bad enough for a comedy troupe to have a bit
on it, maybe it could use some work.)

The worst KBAs I've seen are for United's frequent flyer program. Almost every
question is of the form "What is your favorite X?" X includes items like
"vegetable" or "summer sport." Maybe most people have strong opinions about
the superiority of broccoli and tubing, but I was always just scratching my
head. (The questions were mandatory and you could not write your own.)

~~~
Freak_NL
Yes, my mother's maiden name is Een3oquu+P_a9oez0queiPhaeChaijoh, why do you
ask?

Ironically, you usually can enter a string as answer to those questions that
is more secure than the allowed password.

~~~
TorKlingberg
And then you call phone support and they ask you for it.

~~~
pluma
"I just entered a string of random characters."

"That is correct. Thank you."

~~~
jandrese
mentally: "I knew he was the kind of guy who would do that."

"Go ahead and transfer all of the billing information to this address and
change the email to evilhacker@guy.com. Thanks."

CSR: "Sure, I'm happy to be of help."

------
mylesm
Looks like some good suggestions:

\- Glad they're recommending a stop to the pointless "password must be no
longer than (16, 20, ...) characters". Aren't you storing a constant-length
hash anyway?

\- Why do some logins restrict which ASCII characters can be used? When I see
that I can use any symbol from '%!#&' or whatever list they provide, I can
only imagine it's a really naive SQL-injection defense. Is there any valid
reason for this?

\- And glad to see they're recommending against "security challenges". Half
the time I'm forced to pick a security question, either none of them apply, a
bunch of them are ambiguous ("what's your favorite movie?" \- uhh, I'll give
you a different answer depending on my mood, etc.), or they're easily
searchable ("where did you go to high school?")

Unfortunately I doubt the bad actors will pay too much attention to this. I
know Google is planning on dinging sites that don't use HTTPS, is it possible
they could ding sites for poor password policies?

~~~
rdiddly
I just use the security questions as another password, like my favorite color
is JyQ|l[Duc-I6KrU-0k and I went to elementary school at ?YfBW+Yurh@m$lml":.

~~~
zwily
Those are rough when a customer service rep asks you for one of those over the
phone... :)

~~~
josephg
I do this. I told the CS rep that my password hint was "just random characters
mashed on the keyboard" and she accepted this and moved on. I'm not sure what
to think of the security implications.

~~~
stouset
Replying to sibling.

Worse, if reps can see the answer, then this is equivalent to not hashing the
passwords at all since you have a password-equivalent stored in plaintext.

~~~
serge2k
FYI, if you click on the <x> minutes ago link above the post you can get a
reply box even on new posts.

When I worked for t-mobile it was last 4 of the social unless the customer
requests otherwise.

Few requested otherwise, and usually it was because they were annoyed about
people being able to see part of their SSN.

~~~
developer2
>> they were annoyed about people being able to see part of their SSN

Part of? I worked for AT&T back when they merged with Cingular. We only asked
for the last 4 over the phone, but the entire 9-digit SSN was shown in the
app. Every single low-level employee had (has?) the entire SSN in front of
them. Never dared tell a customer that little fact when they made a fuss over
my having access to their last 4.

------
dcosson
I've written into several companies in the past saying "your password policy
are bad for __ reason", and they always of course write back saying basically
"our security team doesn't care, shut up". There've been quite a few times
I've cancelled accounts right after signing up because of just how absurd they
were (for instance I believe Trade King forces you to click type your password
with the mouse on an on-screen keyboard just in case you have a keylogger
malware).

It's great that there's now a "right answer", and it seems to be based on some
solid research about what actually helps and what doesn't.

In a similar vein I wish there were somehow a standard for http login and
change password requests. Right now password managers are pretty hit or miss
about whether they can actually fill a form and log you in, sometimes it just
can't find the right field, sometimes there's a javascript field check of some
sort so you have to click into the field after the password manager fills it
before you can submit, etc. Having some kind of a standard would let you more
reliably be able to automate logging in, rotating all passwords (at least on
accounts without MFA), etc.

~~~
tjbiddle
There's not "Now a 'right answer'" NIST standards have been around for a
while; the companies you've mentioned are just even more arrogant idiots than
you originally thought :-)

------
mrmagooey
Aren't passphrases kind of a bad choice for passwords? If all you are ever
really guessing is the symbols that make up someones password, and you know
that for example they have 4 words that make the passphrase, then you
effectively only have to iterate 4 symbols with a known list of possibilities
for each symbol (i.e. the dictionary).

If you compare the permutation space of a short passwords (length 7) with
random characters (say ~80 potential symbols), with a long(er) password made
up of 4 english words (say ~3000 potential symbols, the most commonly used
english words).

    
    
        character_symbols = 80
        word_symbols = 3000
        number_of_character_password_symbols = 7
        number_of_word_password_symbols = 4
        permutation_space_characters = character_symbols**number_of_character_password_symbols
        permutation_space_words = word_symbols**number_of_word_password_symbols
        print('%.2E' % permutation_space_characters, '%.2E' % permutation_space_words)
        ('2.10E+13', '8.10E+13')
    

The words space is four times bigger, but in the same magnitude as the short
(bad) password. I'm not an expert here, so I might have stuffed it up, but it
seems like passphrases shouldn't really be encouraged?

I do love the recommendation to remove time-based password expiry though.

~~~
kevhito
Everything in the article is spot on, I only wish they went further and
recommended passphrases more strongly. It's correct horse battery staple and
all that.

As for your calculation, you are about right. Except memorizing a completely
random 8 character password drawn from an 80 symbol alphabet is /extremely/
unpleasant for most people, especially when you may have a few different
passwords you use on a daily or weekly basis. And for passphrases, 6 words
drawn from a 4096-word dictionary is typical. I use that setting (or even 8
words for more important things) and have easily memorized about a dozen
passwords, even ones I use only once every few weeks.

4096 __6 = 4.7e21, about the same as an 11-character random password.

~~~
Biganon
So you have memorized the equivalent of a 60-word nonsensical poem?

~~~
marcosdumay
Well, you only need to memorize the passphrase of your password manager's
file.

------
ryanar
I love this. I despise the fact that my bank restricts passwords lengths to
max 16 chars, hash lengths are constant, it is ridiculous. It is a BANK, if
anything they should be more secure.

Instead they force me to make passwords that easily fit a password mask by
restricting special characters and forcing at least one number, uppercase
letter, etc. They are actually weakening the security in a vain attempt to get
people to make stronger passwords. All they do is make it P@$$w0rd instead, no
increased security, it is so predictable

I think disallowing SMS for 2FA will make it harder to get people to use it,
if they finally decide to signup then they are informed they need an
authenticator program. Also there have been times my phone was dead and I
didnt have a backup plan.

~~~
danielpatrick
> there have been times my phone was dead and I didnt have a backup plan.

This. Just recently this happened to me when I needed to get into my Gmail and
I was shit out of luck. Didn't have my phone on me. The best Gmail would do
was some sort of account reset that would take 2+ days (for good reason). I
was entirely locked out, no solution short of returning home to get my phone.

Anyone recommend a solid backup plan?

~~~
binarycrusader
In the Google case you can print a set of backup codes. See the security page
under your account.

------
mightybyte
> Knowledge-based authentication (KBA) is out

Finally! This is my biggest beef. I've taken to generating long random strings
as answers to these questions but in some cases that's insecure too because
they present you with a multiple choice set of answers and then it's obvious.

Also glad they're getting rid of ridiculous composition rules, hints, and
password expiration.

------
ipsin
I would love to see an explicit recommendation of "no disabling paste" in the
NIST standard... so that I can contact companies that do so and drive me nuts.
The article implies that disabling paste would run afoul of the NIST
standards, but is there actual language I could point to?

~~~
pluma
I would sure hope so. I managed to convince a company to allow paste in their
login form by tweeting them this article: [https://www.troyhunt.com/the-cobra-
effect-that-is-disabling/](https://www.troyhunt.com/the-cobra-effect-that-is-
disabling/)

But I doubt most companies would be this reasonable if they have this level of
stupid in their password handling.

------
serge2k
The don'ts list is pretty much a christmas present from NIST. I hate all of
those things. Worst is the stupid security questions.

~~~
cmurf
Apple still uses those and it annoys me. Yes, others still use them too, but I
give Apple extra crap because I think they should know better by now but
either they don't or don't care.

~~~
whyagaindavid
You can't change your existing password in apple if you forget your secret
question/answer. I gave gibberish to these secret pet/school. Now I am unable
to change my password ;-)

------
tveita
In addition to the standard salting and hashing, they recommend using an
additional key stored separately from the data.

> A keyed hash function (e.g., HMAC), with the key stored separately from the
> hashed authenticators (e.g., in a hardware security module) SHOULD be used
> to further resist dictionary attacks against the stored hashed
> authenticators.

I guess using a pepper is a better-than-nothing measure, if you don't have a
hardware security module.

------
mschuster91
> and should accept all UNICODE characters, too, including emoji

Hell no. This WILL lead to disaster, especially if people store their
passwords in managers that may or may not mess up Unicode. UTF-8, for example,
allows to encode the character "ä" as \xc3\xa4 OR \x61\xcc\x88. They look
visually identical, yet fail any string comparison.

Not to mention the support calls "I'm in $random_foreign_country and don't
have $random_char on my keyboard, cannot login"... good luck trying to match
the kitty emoticon on your Android phone to the random font on a website to
whatever input system iPhone uses. Or when they're used a German Windows
keyboard and suddenly have to use a German Mac - basic stuff like the tilde
symbol ~, pipe symbol | or the (square) brackets {[]} are not marked out on
the keyboard.

I believe that it makes sense to display a warning "Your password may be
impossible to type in another country/using a non-$current_platform keyboard"
when such characters are encountered.

~~~
userbinator
Personally, I think passwords should be opaque sequences of bytes that just
happen to be mostly easily input on a keyboard, but I agree with the warning:
some might even consider such a warning a _good_ thing.

~~~
simcop2387
The problem with that is, which keyboard? USA, German, UK, Japanese?

------
esseti
Question: how do you store data encryption key for each user?

because:

\- you get the password form the user

\- compute the PBKDF2 with iteration and a salt, store iteration$salt$hash
(where hash is the result of the PBKDF2 on the password).

\- when user logs in check that the hash matches the PBKDF2 on password with
iteration and salt.

But now, i've a the data enccryption key (DEK) and i've to store it somewhere.
I can't use the password directly to encrypt the DEK since the lenght must be
32 (or 16, or 24). I should use PBKDF2 to derive a 32 byte hash, but this
value is already stored in the password_hashed field. Should I compute anoterh
PBKDF2 with a different salt and a different iterations for the encryption of
DEK? if so i'll store in the db just$iterations and encryption and apply those
to the password (after the user logs in) to derive an encryption key for the
DEK?

What's a good approach?

------
rdiddly
I'm no security expert, but I'm pleased to see several things being forbidden
that in the back of my mind, I always thought were a little fishy.

------
koolba
What's the only thing worse / stupider / more annoying than secret questions?

Secret questions that don't even have a free form text box for the answer!
That means you can't even put random text in them. You have to select from a
pre-canned list of 5-10 options.

Good riddance!

------
alkonaut
If SMS isn't a recommended 2FA, do they recommend some other means of 2FA?

~~~
niftich
Many [1]. Some examples, my comments in parentheses:

\- Out-of-Band Authenticators (mobile app over secure channel)

\- Single Factor OTP Device (like an OATH push-button, enter 6-digit code TOTP
device)

\- Single Factor Cryptographic Devices (insert into computer)

(among others)

[1]
[https://pages.nist.gov/800-63-3/sp800-63b.html#sec5](https://pages.nist.gov/800-63-3/sp800-63b.html#sec5)

~~~
freehunter
Which is a real shame. SMS might not be perfect, but it's a real help when I
don't have a better means handy. Its better than no 2FA, and it's saved my
butt a few times when I get a text message saying "Here is your login code"
and I'm out walking in the park.

I get a new phone every year, and Google Authenticator sucks for that, but
it's by far the second most common 2FA provider. I just got a new phone today,
and had to go disable 2FA on all my accounts then re-enable it to generate a
new code. SMS is always a good fallback in my experience.

~~~
foxylad
I got a U2F key, which neatly solves the problem as long as you have a USB
port. The integration into the browser makes it painless and fast to use.

Adding bluetooth to work with mobile devices would make it a complete
solution.

Edit: corrected U2FA to U2F.

~~~
nickik
How does a U2F key help you? Most places don't support U2F.

Bluetooth and NFC are standardized, and the first products are out. I really
hope U2F and UAF are gone 'make it' in the market.

~~~
foxylad
I think it's crucial for Gmail, because the popularity of email-based
verification means that if you lose your email account you lose everything.
Including the presidency, in John Podesta's case!

I also use it for Bitbucket and Githib, but I take your point and also hope it
becomes a widespread standard.

------
jrochkind1
> Applications must allow all printable ASCII characters, including spaces,
> and should accept all UNICODE characters, too, including emoji!

Man, I predict a world of hurt here. Maybe it'll be okay if the standards also
very prominently tell you you've got to unicode normalize before hashing, and
tell you what normalization form to use (NFC I think?). Too many
platforms/environments still don't have handy access to unicode normalization
though.

~~~
TJSomething
It actually does:

[https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-
sec...](https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-secret-
verifiers)

------
yellow_postit
Glad to see the knowledge based questions are being phased out, many are sadly
answerable with a cursory search query or leaked in previous breaches.

I didn't see anything in there about security images/indicators, which have
also been shown to be ineffective: "was this bank the image of the man
snowboarding, or the woman skiing...?"

------
bahmboo
Password strength is meaningless when the password can be reset via an email
provider that allows weak passwords.

~~~
foxylad
True. Google does a good job here - they support U2F (and other password
hardening techniques), and additionally report any access from a new device.
You do have to opt in to these measures, but at least they are available.

------
anjanb
Password max length should be minimum 64 chars as specified in
[https://pages.nist.gov/800-63-3/sp800-63b.html#aal_privacy](https://pages.nist.gov/800-63-3/sp800-63b.html#aal_privacy).

We want to know what compliance levels apply for the above rule in an
enterprise product. Anyone knows where I can find compliance levels for
Products targeted for Enterprise customers ?

------
dbg31415
8 characters seems very short.

I like asking people to pick 4 words and a number. Satisfies the length
issues.

But... I love emojis and other things being possibilities. Cool.

~~~
fryguy
They shouldn't pick 4 words, it should be randomly chosen for them.

~~~
syntheticnature
At which point, they hit reset password (either on that page, or on successive
logins) until they get four words that stick trivially... because they're a
normal sentence.

~~~
DenisM
Slow them down?

~~~
syntheticnature
To bend a cliche, users interpret things in their way as damage and route
around it.

------
elchief
Seeing as NIST recommends PBKDF2 over bcrypt and scrypt should we assume that
means NSA can crack PBKDF2 faster / more cheaply?

~~~
nerdy
This is the first thing I thought too. I've consistently heard the opposite
but am not a cryptographer.

The article Sophos links with regards to an explanation for choosing PBKDF2
over bcrypt or scrypt goes over numerous obviously bad practices like
cleartext storage, then states the following, without further detail:

 __ _We’ll recommend PBKDF2 here because it is based on hashing primitives
that satisfy many national and international standards._ __

This seems like a vague and probably misguided line of reasoning. What
specifically would make that recommendation rational? bcrypt wasn 't new in
2010 when NIST published the article recommending PBKDF2, and they haven't
made the switch since. Dual_EC_DRBG was recommended by NIST in 2006 which
makes me deeply skeptical of anything they say.

If anyone could provide the motivation for choosing PBKDF2 in reasonably terms
I'd appreciate it.

~~~
grangerg
The best motivation I've heard is here:
[http://security.stackexchange.com/a/17088/77002](http://security.stackexchange.com/a/17088/77002)

Essentially, blowfish (Bcrypt) doesn't appear to be FIPS-compliant, so if you
have to be FIPS-compliant, you use PBKDF2.

And, considering the rest of the comments about why Bcrypt is preferred over
PBKDF2, it appears it's all about how a GPU gives a significant speed-up for
PBKDF2 but not Bcrypt. But now there are FPGAs that significantly speed up
Bcrypt in similar fashion, so it could all be a wash depending on who you talk
to.

------
Unkechaug
What are the alternatives to SMS two factor authentication? Software like
Authy? Even if it's easy to get around SMS wouldn't utilities like Authy also
have vulnerabilities, or is the idea that at least they can be patched?

------
known
I use passwords from
[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)

------
shthed
Also systems should always notify users if their password or email address has
been changed, immediately alerting that they've been compromised.

2factor authentication is great so you always know if someone is attempting to
login as you.

------
rgaffpalm
Alas, Google forces me to use ASCII only passwords:
[https://support.google.com/a/answer/33386](https://support.google.com/a/answer/33386)

------
ipunchghosts
How the f@@@ on the year 2016 we have a 64 character max length password
requirement!!

~~~
elchief
If you allow unlimited length, that a DoS attack. Ask the devs at Django

~~~
sbuttgereit
For which they set a 4K limit on password length. I think even the commenter
you replied to would find that satisfactory, being much more than 64
characters.

~~~
oneeyedpigeon
It's pretty arbitrary when you get to 64, IMO. If a site enforces a maximum
below that, I'll feel suspicious and treat the site as if it's storing my
password in plain text; that maximum or higher reassures me that they probably
know what they're doing.

Of course, one day, a 64-character password will be brute-forceable in
milliseconds, but we hopefully won't still be having this discussion by then!

~~~
sbuttgereit
I agree, though I also think: why have some arbitrary limit at all? Mind you
the 4K Django limit isn't arbitrary, they know that at some point beyond that
they'll spend too much time in hashing-land and will have opened up a DoS
attack vector.

I would argue 4K is effectively unlimited... maybe in the sense of an
ISP/phone company "unlimited data plan" unlimited, but still... the likelihood
of user knowing of the limit is very small. I use a password manager that
maxes out at 100 characters in its password generator (a default I use
because... why not?) However, in those small cases where I do use contrived
passwords, I make use of passwords that are really pass-sentences (with a few
extras thrown in). It's pretty easy for me to blow by 64 characters (and
sometimes 100) in those cases; not because I think I'm gaining extra security
due to length, but because I'm just throwing out the first, easiest to
remember sentence that crosses my mind and that I know will be reasonably
secure. A service that flummoxes that effort just makes it less likely I'll
use the service (assuming that it's use is discretionary).

------
huilee
FAL3 is not used in LOA- seems like it won't be used much.

------
selljamhere
Relevant xkcd: [https://xkcd.com/936/](https://xkcd.com/936/)

