cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Matthew
Newcomer I

NIST new ruling on passwords

I wanted to see how members on here felt about NIST new draft of password policy suggestion.   

 

What’s new ?

What are the major differences between current received wisdom about “secure passwords” and what NIST is now recommending?

Some of the recommendations you can probably guess; others may surprise you.

We’ll start with the things you should do.

Favor the user. To begin with, make your password policies user friendly and put the burden on the verifier when possible.

In other words, we need to stop asking users to do things that aren’t actually improving security.

Much research has gone into the efficacy of many of our so-called “best practices” and it turns out they don’t help enough to be worth the pain they cause.

Size matters. At least it does when it comes to passwords. NIST’s new guidelines say you need a minimum of 8 characters. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.)

Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.”

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

This is great advice, and considering that passwords must be hashed and salted when stored (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length.

We often advise people to use passphrases, so they should be allowed to use all common punctuation characters and any language to improve usability and increase variety.

Check new passwords against a dictionary of known-bad choices. You don’t want to let people use ChangeMethisisapasswordyankees, and so on.

More research needs to be done into how to choose and use your “banned list,” but Jim Fenton thinks that 100,000 entries is a good starting point.

The don’ts

Now for all the things you shouldn’t do.

No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”

Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as pA55w+rd.

No password hints. None. If I wanted people have a better chance at guessing my password, I’d write it on a note attached to my screen.

People set password hints like rhymes with assword when you allow hints. (Really! We have some astonishing examples from Adobe’s 2013 password breach.)

Knowledge-based authentication (KBA) is out. KBA is when a site says, “Pick from a list of questions – Where did you attend high school? What’s your favourite football team? – and tell us the answer in case we ever need to check that it’s you.”

No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.

The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

There’s more…

NIST also provides some other very worthwhile advice.

All passwords must be hashed, salted and stretched, as we explain in our article How to store your users’ password safely.

You need a salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the “stretching” algorithm PBKDF2 with at least 10,000 iterations.

 

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

 

I think this is a great step.  The 90 day rotation only made users change the base of their password append with a date or numerical number.  Example, TH!S1sMYp2ssw0rd1, THIS1sMYp2ssw0rd2, etc.    Once the base of the password was figured out or phished, gaining access is easier.  

 

I still educate my users on passphrases and why they better as a password substitute but our policy (and compliance) rules make it hard to use a nice passphrase.  

 

I have also educated my users on password management solutions.  This allows for a long passphrase as the master password that bypasses local policy restrictions.  Local solutions work well if you have an office that you will always log into at work.  The database for this solution should be stored on a network share for data redundancy.   Also, Cloud solutions are acceptable if you have a user who is on the move or never logs in from the same device.   I would only caution that your Cloud solution encrypts the data and either you hold the decrypt key or have it part of your master password.  

 

 

Thoughts?


US Army Veteran - CISSP

It's not a matter of IF but a matter of WHEN. What are you going to do when it happens?
111 Replies
KenT
Viewer II

I'm a longtime opponent to the arbitrary composition rules. Especially those that reduce the selection space of possible passwords and dumb algorithms that are supposed to prevent bad passwords that aren't well thought out.

 

https://www.quora.com/Which-is-the-password-you-would-never-use/answer/Ken-Tanaka-13

J_Cook
Viewer II

Not sure that this particular NIST publication has much value when the requirements in NIST 800-171 explicitly require complexity in passwords.  Follow the recommendation and be out of compliance...

Tamang
Newcomer I

Arrived this morning in my inbox from US-CERT

 

https://www.dhs.gov/sites/default/files/publications/Week5TipCard-%20508%20compliant_0.pdf 

 

 "Make your passwords long & strong. Use complex passwords with a combination of numbers, symbols, and letters. Use unique passwords for different accounts. "

 

NIST/Feds needs to agree first.

richardrblake
Viewer II

I absolutely agree with you --and disagree with NIST-- on password expiration.

 

Human beings make mistakes. For example, even after being admonished not to do so, users will use the same password for their work account as they do for web sites they sign up for (using their work email address, of course). If (err... .WHEN) one of those web providers is breached, those passwords are now on the web and are being passed around for people to try out.

 

The LinkedIn breach is a great example of this...

 

If you set at least some expiration to the password, those old passwords floating around the dark web get rotated out. I'm not in favor of frequent rotation, but leaving them permanent? Bad idea. I know the guidelines suggest "after a breach" as a trigger for change, but we generally find out a username & password were compromised (again, LinkedIn) after it's already been passed around for a while.

 

60 days is too soon. 90 days? Twice a year? Quarterly or biannual refresh might be worth keeping to get stale passwords/passphrases out of circulation.

grasshopper
Viewer II

Every article about password strength should set a link to this XKCD comic:

XKCD Comic on password strength

 

 

JJP
Newcomer I

Not free but one of the better tools in this field.
https://www.detack.de/en/resources
JJP
Newcomer I

Yes, but... Its a beginning, not an end to the question.
Marubadi
Viewer II

Nice and knowledgeable.  Though we have lot of policies defined in the system especially for passwords there are many programs which reads the ASCII characters.

 

 


@Matthew wrote:

I wanted to see how members on here felt about NIST new draft of password policy suggestion.   

 

What’s new ?

What are the major differences between current received wisdom about “secure passwords” and what NIST is now recommending?

Some of the recommendations you can probably guess; others may surprise you.

We’ll start with the things you should do.

Favor the user. To begin with, make your password policies user friendly and put the burden on the verifier when possible.

In other words, we need to stop asking users to do things that aren’t actually improving security.

Much research has gone into the efficacy of many of our so-called “best practices” and it turns out they don’t help enough to be worth the pain they cause.

Size matters. At least it does when it comes to passwords. NIST’s new guidelines say you need a minimum of 8 characters. (That’s not a maximum minimum – you can increase the minimum password length for more sensitive accounts.)

Better yet, NIST says you should allow a maximum length of at least 64, so no more “Sorry, your password can’t be longer than 16 characters.”

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

This is great advice, and considering that passwords must be hashed and salted when stored (which converts them to a fixed-length representation) there shouldn’t be unnecessary restrictions on length.

We often advise people to use passphrases, so they should be allowed to use all common punctuation characters and any language to improve usability and increase variety.

Check new passwords against a dictionary of known-bad choices. You don’t want to let people use ChangeMethisisapasswordyankees, and so on.

More research needs to be done into how to choose and use your “banned list,” but Jim Fenton thinks that 100,000 entries is a good starting point.

The don’ts

Now for all the things you shouldn’t do.

No composition rules. What this means is, no more rules that force you to use particular characters or combinations, like those daunting conditions on some password reset pages that say, “Your password must contain one lowercase letter, one uppercase letter, one number, four symbols but not &%#@_, and the surname of at least one astronaut.”

Let people choose freely, and encourage longer phrases instead of hard-to-remember passwords or illusory complexity such as pA55w+rd.

No password hints. None. If I wanted people have a better chance at guessing my password, I’d write it on a note attached to my screen.

People set password hints like rhymes with assword when you allow hints. (Really! We have some astonishing examples from Adobe’s 2013 password breach.)

Knowledge-based authentication (KBA) is out. KBA is when a site says, “Pick from a list of questions – Where did you attend high school? What’s your favourite football team? – and tell us the answer in case we ever need to check that it’s you.”

No more expiration without reason. This is my favourite piece of advice: If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.

The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

There’s more…

NIST also provides some other very worthwhile advice.

All passwords must be hashed, salted and stretched, as we explain in our article How to store your users’ password safely.

You need a salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the “stretching” algorithm PBKDF2 with at least 10,000 iterations.

 

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

 

I think this is a great step.  The 90 day rotation only made users change the base of their password append with a date or numerical number.  Example, TH!S1sMYp2ssw0rd1, THIS1sMYp2ssw0rd2, etc.    Once the base of the password was figured out or phished, gaining access is easier.  

 

I still educate my users on passphrases and why they better as a password substitute but our policy (and compliance) rules make it hard to use a nice passphrase.  

 

I have also educated my users on password management solutions.  This allows for a long passphrase as the master password that bypasses local policy restrictions.  Local solutions work well if you have an office that you will always log into at work.  The database for this solution should be stored on a network share for data redundancy.   Also, Cloud solutions are acceptable if you have a user who is on the move or never logs in from the same device.   I would only caution that your Cloud solution encrypts the data and either you hold the decrypt key or have it part of your master password.  

 

 

Thoughts?



asredux
Newcomer I


@Matthew wrote:

 

NIST also provides some other very worthwhile advice.

All passwords must be hashed, salted and stretched, as we explain in our article How to store your users’ password safely.

You need a salt of 32 bits or more, a keyed HMAC hash using SHA-1, SHA-2 or SHA-3, and the “stretching” algorithm PBKDF2 with at least 10,000 iterations.

 


Just to be clear, this is advice from *Sophos*, not NIST.  Two things... 1) salt length; 2) nested HMAC

 

1. The above is wrong (but probably just a typo by Sophos; should be *bytes*).  A common recommendation is for salt length to match the length of the hash digest, but half is probably okay.

 

2. Using HMAC... specifically with SHA-3.  Presumably the advice to use HMAC along with a hash function is to guard against length extension attacks.

From https://keccak.team/keccak_strengths.html:

Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence does not need the HMAC nested construction.

 

EkanemPhilip
Newcomer I

hi asebastian

 

 
I have been asked lots of times by users
 
 
 
 
 
 
 

 

Regards

 

Philip