After reading some of the latest research from NIST and some good summaries, for example: https://www.cisoadvisory.com/cai-blog/2016/10/24/nist-proposes-new-approach-to-passwords

When proposing a chance to the usual password policy of "upto 8 characters, with no spaces but special characters, whilst standing upside-down blindfolded", is this credible to cite?

In summary:

  • Use 2FA
  • Check against known bad passwords
  • Encourage long password / phrases

Three questions:

  1. Is it acceptable to use 2FA only for admins / privileged access?

  2. Is there a (reasonably) canonical list of bad passwords to check against? Is there a prefrred method such as lower case everything before checking?

  3. What's a reasonable minimum length?

Edit to Add One more aspect, scanning through the password list linked below by @DKUNCKLES (https://security.stackexchange.com/a/158176/73340) a lot of passwords are short - shorter than 12 characters.

So, by that rationale, just making a minimum password length of 12 characters you immediately eliminate silly or pointless passwords? Right?

Or would you check for the contents? Is "password123password123" harder to crack than "password123"?

  1. Level's of acceptability are determined based on an organizations or individuals risk appetite. 2FA is not a silver bullet, and as a pen-tester I'm going to pop any box I can (whether it be admin, or not) and then work on escalating privileges. 2FA will not protect you against system vulns that can provide access to SYSTEM or root, so if I have a foothold in your network via a compromised workstation I'm going to start fingerprinting services and try to get domain admin. Compromised end-user workstations also provide potential pivot-points into additional networks (perhaps dev environments where things may not be as secure). If you want to make life harder for threat actors, enable 2FA org wide if possible.

  2. There are a lot of these lists available, but check out This GitHub Repo which contains several lists of the most common passwords utilized. A warning: You will be shocked and dismayed at what the most common passwords that are still being used.

  3. Again, your reasonable minimum length is going to depend on what you're trying to secure. Ultimately as security people we'd love to see massively long passwords with high entropy spread across an organization, however that may not be feasible in many instances. Security is important but should minimally impede an organizations ability to be productive. A LUKS decryption key for a very sensitive server's full disk encryption which is only entered when the system boots up is likely to be very long more random. Conversely, your average end-users login to the workstation which is used every time they want to access their workstation is likely to be shorter and much less random. Despite what any best practice says you need to find the sweet spot of secure-random passwords with usability.

EDIT re: Password rotation : The concept of forcing people to change their password is a contentious topic to say the least. On one hand you forcing them to change their password potentially mitigates password replay attacks. On the other hand you get password rotating and minimal changes (password#1, password#2, password#3) etc.

It's important to understand that Pentesting is not a truthful representation of your threat exposure for one simple reason: time. Penetration tests are limited timeframe engagements, whereas an attack with an axe to grind has a much larger window of opportunity. I might spend two weeks with a client, but once an attacker has a foothold in the network there's no telling how long they might poke around undetected. If I'm running a 2 week pen-test and there's no luck with password replay attacks after a few attempts, I'm likely going to move on to other attack vectors. It's easier for me to XSS or Spear Phish someone that waste CPU power on brute forcing or attempting to re-use people's passwords.

Now with that said, I like forcing users to change their passwords even though I inevitably know that passwords will get recycled. If I set a password policy to have users change their password every 60 days, and remember their previous 6 passwords I know that in a year there are 60 days where a stolen set of credentials might work. As a sysadmin I like those odds, as an attacker I don't. If users could be trusted to use a completely different password on each service they use, then ditching the age-old adage of "Change your password every x days" would become feasible, but that's nothing more than a pipe dream.

As there is no way to enforce staff to use unique password on each service (at least reaonsably unqiue (ie not password1 for your email, password2 for your laptop, etc) then I don't think password policies are going anywhere any time soon. Knowing that passwords will likely get reused, the responsibility then is on the organization to implement additional controls (2FA, network segregation, Intrusion Detection, etc) to round out their internal security.

  • Great answer, could you expand, from your experience in pen testing, how to overcome the ingrained "wisdom" of changing passwords every 30 days for example? Which just leads to simple passwords being rotated... – RemarkLima Apr 26 '17 at 13:37
  • @RemarkLima added edit to address your question. – DKNUCKLES Apr 26 '17 at 13:56

All depends on the risk and threats... Do you really want to use 2FA to get access to your own phone (fingerprint + long passphrase)? On the other end a sensitive application accessed through an uncontrolled network really needs strong encryption and strong authentication.

And currently, I think that the state of the art best remote authentication is still the good old smartcard: something you have (the card), something you know (the pin code) and as a security, the card blocks itself is a wrong password is entered more than n times (n between 3 and 5). An behind that you can use a strong asymetric key for authentication, the key being constrained inside the smart card.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.