cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Kempy
Newcomer III

Passphrase advice

Why is it that 90% of passphrase advice out there never includes the recommendation to use a password filter that will ban dictionary words, low entropy, and leet speak substitutions etc. 

 

Why expend the effort cracking password hashes when one can drop in a dll or a few extra functions and deal with weak passwords at source before they become a problem or entry point for an attacker.

 

Is the internet really lacking enough info for people to go build better filters...

 

What are your thoughts?

 

5 Replies
denbesten
Community Champion

You might check out NIST SP 800-63b, particularly §5.1.1.2 and Appendix A.  It is (IMHO) the best source for authentication guidelines.  

 

 

Current thoughts are that:

  • human factors play a critical role (e.g. the ability or inability to memorize a password) 
  • complexity rules are counter-productive
  • long passwords are better than complex passwords
  • we should depend less on passwords (e.g. use multiple factors)
  • rate-limiting of attempts is important.
  • bad-password lists are a good thing.
  • copy/paste of passwords is a good thing as it encourages use of password vaults
CISOScott
Community Champion

An interesting thought, What if we put all of these filters in place (leet speak, dictionary words, etc.) doesn't that make it easier for the hackers to make rainbow tables of what passwords can't be and then deduce or make rainbow tables of acceptable passwords?

denbesten
Community Champion

If you limit your passwords to exactly 8 lower-case characters, your pool would be in excess of 209,000 million passwords.  Natural language dictionaries are somewhere around 0.25 million words, and bad-password lists tend to be around 1 to 10 million.  Subtracting them out of your pool would not save you very much time, space or effort.  

 

 

That said, the goal of a rainbow table is to find a password that for each of the hashed values.  Doesn't matter if it is what the user originally entered; just that it hashes to the same value.   Complexity rules don't help in a rainbow attack.   The defenses are protecting your hashes from disclosure, salting the hashes and using longer hashes.  

 

Kempy
Newcomer III

So essentially you are saying you are happy for your users to use any of the passwords from any top known password lists, such as rockyou etc, based upon;

 

A. fear the dilution of the potential pool

B. Imposed a min&max limit of 8 characters

C. storage requirements

 

Most organisations typically use Windows, thus the central authentication is with active directory, If you dump the users out, the hashes are not salted.

Increasing the character set does help increase the potential pool thus addresses one of your concerns as would increasing the minimum limit.

Setting a maximum limit is counter productive, that said there are upper limits of 254 characters on Windows before any issues, anything longer won't allow logon (Can be set within AD, however the clients Gina seems to trim thus can never match the hash).

 

For point C. the storage requirements can be solved by not building the pre-computed rainbow table as a banned list and inverting the logic used to build it to run at the expense of CPU as and when users reset credentials. Thus you can use a smaller dictionary (currently have one at 80k words 915kb).

 

Complexity rules are bad when users try to use that complexity as a substitution mechanism to attain shorter 'P4$£w0rds' vs 'My long and strong phrase' which has 2 of the complexity rules with space being valid but not classified in any of the character sets is surprising, but just hash tagging the phrase and even if the attacker knew this would still be too expensive for them at 26 characters ^(54).

 

I have a working solution that only took a few weeks research and development which is running in production environments for last few years without problems.

This is saving the team many hours each year from dumping the hashes and cracking them, to audit for weak passwords that users whom have had training are still setting because they could. 

 

These functions can be translated to other platforms (Azure now has the capability). 

 

Hence my original post, and so far it's looking like a perception issue.

Thank you for your comment and everyone else who is contributing.

CISOScott
Community Champion


@Kempy wrote:

So essentially you are saying you are happy for your users to use any of the passwords from any top known password lists, such as rockyou etc, based upon;

 

A. fear the dilution of the potential pool

B. Imposed a min&max limit of 8 characters

C. storage requirements

 


No what I was saying is basically if you make the restrictions too complex users will write them down and use them everywhere they can OR constantly forget them and generate a helpdesk ticket to unlock/change it. It is the standard line in security do I make it too strict or too convenient or somewhere in between. We all know that it is a tightrope walk and you have to come up with some compromise. I went to work at one place and they had these requirements set to very strict. They realized a couple of years later that it was counter-productive (people writing them down and lots of helpdesk tickets for password resets) and they went back to a more relaxed version of the rules. Here were their requirements:

1) No Leet speak of dictionary words

2) No dictionary words

3) Regular users minimum 12 character length

4) Admin users minimum 14 character length

5) One out of the 4 groups (upper, lower, number, symbol)

6) No common passwords or keyboard walks (1qaz@WSX, qwerty1234, etc.)