Rules to Choose a Secure Strong Password

The age-old password rules have changed dramatically over the years and are barely relevant in the modern days, many thanks to the hackers that keep their weapon sharpened when it comes to cracking passwords.

Here are a few good readings and materials that summarize very well how to choose a good, strong and secure password in the modern world.

How Secure Your Password is?

Let’s head over to How Secure is My Password to find out.

Bruce Schneier’s Choosing a Secure Password

The article was published in 2014 but still relevant in today’s world. It lays out several studies on password strength and simply points out that

Pretty much anything that can be remembered can be cracked.

But there is still one scheme that seems to work, so-called “Schneier scheme”:

So if you want your password to be hard to guess, you should choose something that this process will miss. My advice is to take a sentence and turn it into a password. Something like “This little piggy went to market” might become “tlpWENT2m”. That nine-character password won’t be in anyone’s dictionary. Of course, don’t use this one, because I’ve written about it. Choose your own sentence – something personal.

For example:

  • WIw7,mstmsritt… = When I was seven, my sister threw my stuffed rabbit in the toilet.
  • Wow…doestcst = Wow, does that couch smell terrible.
  • Ltime@go-inag~faaa! = Long time ago in a galaxy not far away at all.

Schneier also adds a few more rules on top of how to choose a good password:

  1. Never reuse a password you care about. Even if you choose a secure password, the site it’s for could leak it because of its own incompetence. You don’t want someone who gets your password for one application or site to be able to use it for another.
  2. Don’t bother updating your password regularly. Sites that require 90-day—or whatever—password upgrades do more harm than good. Unless you think your password might be compromised, don’t change it.
  3. Beware the “secret question.” You don’t want a backup system for when you forget your password to be easier to break than your password. Really, it’s smart to use a password manager. Or to write your passwords down on a piece of paper and secure that piece of paper.
  4. One more piece of advice: if a site offers two-factor authentication, seriously consider using it. It’s almost certainly a security improvement.


Jeff Atwood’s Password Rules are Bullshit

TL;DR: There is one rule to bring them all, and in the darkness bind them, the length. Whatever you want, just make sure it’s long enough to be a reasonable password.

In detail,

  1. Password rules are bullshit
    • They don’t work.
    • They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn’t have a number or symbol in it. I just double checked my math textbook, and yep, it’s possible. I’m pretty sure.
    • They frustrate average users, who then become uncooperative and use “creative” workarounds that make their passwords less secure.
    • They are often wrong, in the sense that the rules chosen are grossly incomplete and/or insane, per the many shaming links I’ve shared above.
    • Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won’t take my word for it, read this 2016 NIST password rules recommendation. It’s right there, “no composition rules”. However, I do see one error, it should have said “no bullshit composition rules”.
  2. Enforce a minimum Unicode password length
    • It’s simple. Users can count. Most of them, anyway.
    • It works. The data shows us it works; just download any common password list of your choice and group by password length.
    • The math doesn’t lie. All other things being equal, a longer password will be more random – and thus more secure – than a short password.
    • Accept that even this one rule isn’t inviolate. A minimum password length of 6 on a Chinese site might be perfectly reasonable. A 20 character password can be ridiculously insecure.
    • If you don’t allow (almost) every single Unicode character in the password input field, you are probably doing it wrong.
    • It’s a bit of an implementation detail, but make sure maximum password length is reasonable as well.
  3. Check for common passwords
  4. Check for basic entropy
  5. Check for special case passwords


Two more bonus readings from Jeff: Hacker, Hack Thyself & The God Login.

Troy Hunt on Password Strength Indicators

Troy uses a true sample to demonstrate why Password Strength Indicators sometimes help people choose dumb choices, and points out that

Password strength meters which simply run JavaScript in the client and apply basic mathematics are woefully inadequate. Likewise, websites applying similar maths to enforce “strong” passwords in no way guarantee that actual strong passwords will be chosen. All these calculators neglect the human element of passwords and that’s an enormously important part of the picture.

He also suggests:

Fundamentally, it’s an education issue and the key tenets people need to understand boil down to the risks of password reuse and, of course, what genuinely constitutes a strong password.


UK NCSC’s Password Guidance

The UK NCSC (part of GCHQ – Uk equiv to NSA) published a good discussion document a while back that contains some useful password guidance that simplifies the password policy, including:

  1. Change all factory-set default passwords.
  2. Take advantage of good password manager software.
  3. Eliminate password expiry policy to avoid placing more burden on users.
  4. No sharing passwords
  5. Use technical controls to defend against automated guessing attacks, rather than relying on users to generate complex passwords.
  6. Never re-use passwords between work and home.
  7. Account lockout, throttling, and protective monitoring are powerful defenses against brute-force attacks on enterprise systems and online services.
  8. Never store passwords as plain text, always hashing and salting before storing them.

Source: UK NCSC’s Password Guidance

Microsoft Password Guidance

It provides Microsoft’s recommendations for password management based on current research and lessons from their own experience as one of the largest Identity Providers in the world.

Here is some advice to IT admins:

  • Maintain an 8-character minimum length requirement (and longer is not necessarily better).
  • Eliminate character-composition requirements.
  • Eliminate mandatory periodic password resets for user accounts.
  • Ban common passwords, to keep the most vulnerable passwords out of your system.
  • Educate your users not to reuse their password for non-work-related purposes.
  • Enforce registration for multi-factor authentication.
  • Enable risk-based multi-factor authentication challenges

Source: Microsoft Password Guidance

Security Baseline for Windows 10 and Server v1903

The new Windows Feature Update brings very few new Group Policy settings but the new draft baseline did drop a few policies that were recommended before. One of them is the dropping of the password-expiration polices that require periodic password changes.

Why are we removing password-expiration policies?
First, to try to avoid inevitable misunderstandings, we are talking here only about removing password-expiration policies – we are not proposing changing requirements for minimum password length, history, or complexity.
Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.
If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you.
Our baselines are intended to be usable with minimal if any modification by most well-managed, security-conscious enterprises. They are also intended to serve as guidance for auditors. So, what should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration?
The results of baseline compliance scans are usually measured by how many settings are out of compliance: “How much red do we have on the chart?” It is not unusual for organizations during audit to treat compliance numbers as more important than real-world security. If a baseline recommends 60 days and an organization with advanced protections opts for 365 days – or no expiration at all – they will get dinged in an audit unnecessarily and might be compelled to adhere to the 60-day recommendation.
Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Source: Security baseline (DRAFT) for Windows 10 v1903 and Windows Server v1903

Leave a Reply

Your email address will not be published. Required fields are marked *