Your password is only as strong as your password policy

Many people think a pentest is only about finding flaws in software. That is just half of it. Many risks lie in the rules an organisation sets for itself, and the password policy is one of the most important of those. In this blog we show how attackers find out passwords, which well-meant rules backfire and how to do it right.

What is a password policy?#

A password policy is a set of rules a password has to meet, such as a minimum length. The goal: preventing someone from choosing password or 123456. Software can enforce these rules when an account is created. On top of that, an organisation can make agreements with its employees, for example about accounts on external websites with weak requirements.

How do attackers get your password?#

• Guessing at scale (brute force). A computer tries a huge number of passwords in quick succession (MITRE ATT&CK).
• Leaked data. After a data breach, attackers compare the stolen data with millions of known passwords. A commonly used password is found in no time.
• Without hacking. For example through unencrypted network traffic, or because every new employee gets the same default password.

Why 'complex' rules are not enough#

If an attacker tries every possible combination, length and variety help enormously. A password of 10 digits has 10 billion possibilities. Allow lowercase letters as well, and that becomes more than 3.6 quadrillion.

But smart attackers don't try everything. They start with the passwords people choose most often. A policy of at least 5 characters, 1 uppercase letter and 1 digit allows A132Z, but also Test1. Guess which one gets tried first? That is why checking for known passwords matters more than requiring certain types of characters.

RockYou: the list every hacker knows#

In 2009 app maker RockYou was hacked, exposing the email addresses and passwords of 32 million users. The US regulator FTC later fined the company for it (FTC). The leaked passwords still circulate as a list called rockyou.txt. Attackers and pentesters alike use lists like this to guess passwords and crack hashes. If your password is on it, it will be found within seconds.

A new password every month? Better not#

Many organisations force employees to change their password regularly. That feels secure, but in practice people end up choosing ever more predictable passwords. A strong password in week 1 becomes Temporary1Password3 a few weeks later.

That is why modern guidelines advise against periodic changes. Only change a password when there are signs that it has leaked.

These passwords belong on the blocklist#

We advise rejecting passwords that contain:

• the company name or words associated with it;
• months and seasons (October2026);
• variations on 'welcome' and 'password' (P@ssw0rd);
• sequences such as 123456 and qwerty;
• personal details, such as a date of birth.

How do you store passwords securely?#

Passwords must never be stored in readable form. Instead, a system stores a hash.

What is a hash?#

A hash is a digital fingerprint of your password. A hash function turns every password into a fixed string of characters, such as 9f2c…a71e. The same password always produces the same hash, but the calculation only works one way: you cannot work out the password from the hash. When you log in, the system calculates the hash of what you type and compares it with the stored hash. This way the system can check you without ever keeping your password.

What is a salt, and why do we use it?#

A hash on its own is not enough. Attackers have ready-made tables with the hashes of millions of known passwords, so-called rainbow tables. If they find a stolen hash in such a table, they immediately know the password (MITRE ATT&CK).

That is why we add a salt per user: a random, unique string of characters that is attached to the password before hashing. The salt is not secret and is stored alongside the hash. The effect:

• Ready-made tables no longer work. The attacker has to crack every hash separately, using that one user's salt.
• Identical passwords can't be recognised. If two people choose Summer2026!, their own salts still give them completely different hashes.

The US standard NIST requires passwords to always be salted and hashed, with a salt of at least 32 bits (NIST SP 800-63B). NIST defines a salt as a non-secret value that prevents an attacker from reusing work done for one user against another (NIST glossary).

Why a slow hash function?#

Finally, we choose a hash function that is deliberately slow, such as Argon2id or bcrypt (OWASP). For a single login attempt you won't notice a thing. But an attacker who wants to try billions of passwords is slowed down considerably.

What a good password policy looks like#

We follow the US standard NIST SP 800-63B, which was updated in August 2025. MITRE also lists a password policy following NIST as a measure against password cracking (MITRE ATT&CK):

• Length over complexity: at least 15 characters, or 8 when two-factor authentication is also used.
• Allow long passwords, up to at least 64 characters, including spaces.
• No required character types such as 'at least one symbol'.
• Reject known and leaked passwords.
• No periodic changes, only when a leak is suspected.
• Limit the number of login attempts and allow password managers.

Tips for yourself#

1. Use a passphrase of a few random words, such as bicycle lantern ocean pancake. Avoid things you share online, like your dog's name.
2. Use a different password for every account.
3. Use a password manager, such as KeePass.
4. Turn on two-factor authentication wherever you can.

In conclusion#

A strong password policy is not about complicated rules, but about length, keeping out known passwords and secure storage. That is why we also look at these choices during a pentest. After all, the best lock is useless if the key is under the doormat.

Jeremy Melis03-11-2026