Everything About Passwords

Introduction: Are Most Password Policies Just Bad?

If you’ve ever worked with a computer for any company in the last 20 years, you’ve probably encountered password policies that make you wonder if they were designed by someone who’s never actually had to use a computer.

How many of these have you encountered in your personal or professional life?

• Change password every 30-90 days
• Password must be 8-12 characters (with arbitrary upper limits like 20-32 chars)
• Must have uppercase, lowercase, numbers, special characters

Or even worse, have you encountered some of these?

• Password sharing for shared SaaS accounts
• Password reuse across multiple accounts (everyone does this)
• Sending passwords through Slack, Teams, email, or sticky notes
• Storing passwords in .txt .xlsx or anything like that

Here’s the thing: there is a massive disconnect between “experts” offering advice on secure authentication systems and the reality of user behaviour. You might even think that these policies are created by people who read outdated guidelines, copy-paste from compliance checklists, and call it “security.”

The result? Overly complex rules that make passwords weaker while frustrating users.

Meanwhile, while companies force users to jump through these hoops, the actual attack vectors that compromise passwords - credential stuffing, database breaches, social engineering - have nothing to do with whether your password has a number in it.

This blog covers everything about passwords - the mathematics of password strength, how passwords are actually attacked in practice, and why most “enterprise security” recommendations ignore both technical reality and human behaviour.

Let’s start with something many security professionals get wrong: what actually makes a password strong.

The Mathematics of Password Security

Let’s start with a short quiz.

In order to answer why that is the case, I need to cover some basics like entropy, complexity and real attack calculations as well as forms of attacks.

Understanding Entropy vs Complexity

Although Password entropy and complexity sound similar, they are not the same thing.

So the example with higher complexity is less secure? How can that be? That’s where entropy comes into place.

Password Entropy Calculations

Now that we established what entropy is and a way to calculate we can see that increasing either the password length $L$ or the size of the character set $N$ increases the entropy and thus the password strength.

Now let’s go back to my previous example of ZU$Xgb8! vs fishwithahat and calculate their entropy.

Why Complexity Rules Are Backwards

Understanding why complexity rules fail is only part of the story. Effective defenses require proper examination of how attackers actually target passwords in practise.

Most password policies force this pattern:

• At least 1 uppercase letter
• At least 1 lowercase letter
• At least 1 number
• At least 1 special character
• Minimum 8 characters

The Issue: This dramatically reduces the actual search space because users follow predictable patterns.

Here are 2 examples of how real users behave in a situation where there are two policies.

• Policy A: Forced Complexity (8 chars)
• Policy B: Simple but long (12 chars)

Now that we’ve established why length matters more than complexity, let’s look at how attackers actually exploit the gap between theoretical and practical password strength.

How Passwords Are Actually Attacked

These attack methods highlight why proper password storage is critical. Appropriate storage controls can be the difference between a minor incident and a catastrophic breach.

Attack Method Breakdown

There are many attack vectors that can compromise a password and here I try to cover most relevant ones. Notice how most “security advice” focuses on defending against the least likely attacks while ignoring the methods that actually work.

Each attack method below includes:

• Description: What the attack actually does
• Speed: How fast it works in practice
• Prerequisites: What the attacker needs
• Defense: How to actually protect against it
• Real-World Usage: How common it actually is (the part that matters most)

Online vs Offline: The Critical Distinction

Regardless of how many attack techniques there are on passwords, reality is that most if not all attacks don’t actually involve “guessing” or cracking these days. It’s far more common and actually much easier for attackers to use social engineering or other techniques to get a hold of your password.

In practice, guessing or cracking requires the following:

• Compute power
• Energy
• Time

Compute and energy have significant impact on the overall costs of attack, often making it inefficient or impractical in real life scenarios. However, time is something that can be limited further, almost eliminating the impact of online only guessing attacks. This does not apply to offline attacks described below.

Rate limiting often implements exponential backoff to keep increasing the time between guesses, eventually growing so large that it can take months or years between guesses. This completely eliminates guessing as no attacker will wait days or months between each guess.

Unfortunately this is not the case for offline attacks.

When Attackers Get Your Database

While online guessing is uncommon and most often ineffective, offline cracking is a completely different ball game.

Compliance and Regulatory Requirements

We can’t talk about passwords without mentioning their storage. This topic is far too broad to be discussed in detail but the importance of it must be stated.

Let’s briefly look at some common compliance requirements from GDPR, PCI-DSS and enterprise standards like NIST, ISO and SOC.

Password Storage: The Technical Foundation

What is Hashing?

Here is a visual diagram to help explain the maths overload from earlier. We again use fishwithahat as the input with a common hashing algorithm SHA-256. You would never use SHA-256 for password hashing, the only reason I use it for this example is because it’s the most widely known hashing algorithm.

Note how the same input always produces the same output and a single change within input, results in drastic change of the output.

flowchart TD
    A["fishwithahat"] --> B[SHA-256]
    A2["fishwithahat"] --> B2[SHA-256]
    B --> C["7a8b9c1d2e3f45...6g7h
    🔒 Always identical
    (Deterministic property)"]
    B2 --> C2["7a8b9c1d2e3f45...6g7h
    🔒 Always identical
    (Deterministic property)"]

    F["fishwithbhat
    (5th letter: a→b)"] --> G[SHA-256]
    G --> I["3x4z8m7n9k5j2l...5w8q
    🌊 ~50% bits flipped
    (Avalanche criterion)"]

    class F warning
    class I amber

We can more generically visualise this process as inputting any digital data through a hash function to produce a fixed length output.

flowchart TD
A["Any Size Input:
📄 'hello world' 
📊 1GB file 
🔢 123456789"] --> B["Hash Function e.g SHA-256"] 
B --> C["Fixed Size Output 256-bit digest 64 hex characters"]

What is Salting?

These salt values are often stored together with the hash of the password on a table somewhere in a database and looks something like this:

Here’s how salting works in practice using our earlier example fishwithahat

flowchart TD
    A["Password: fishwithahat"] --> D[Combine]
    B[Generate Random Salt] --> C["Salt: x7k9m2n4p8q1"]
    C --> D
    D --> E["fishwithahat + x7k9m2n4p8q1"]
    E --> F[SHA-256]
    F --> G["Salted Hash:
    9f2a8b3c7d4e5f..."]

    class C primary

The same password with different salts produces completely different hashes:

flowchart TD
    A["fishwithahat"] --> C[Combine with Salt 1]
    B["Salt 1: a1b2c3d4"] --> C
    C --> D[Hash Function]
    D --> E["Hash 1:
    3f7a9b2c4d..."]

    A2["fishwithahat"] --> C2[Combine with Salt 2]
    B2["Salt 2: x7k9m2n4"] --> C2
    C2 --> D2[Hash Function]
    D2 --> E2["Hash 2:
    8x4z7m1n5k...
    (Completely different)"]

    class B primary
    class B2 teal
    class E warning
    class E2 amber

How to Salt like master-chef?

It’s quite surprising that even though doing proper password salting is relatively easy and inexpensive, it’s still widely done incorrectly.

Proper salt requires:

• Minimum length of at least 128 bits
• Salt must be generated with a proper cryptographically secure random function CSPRNG
• Stored separately from the password hashes (Preferred but not required)
• MUST BE UNIQUE for each password
• Should be applied to password before hashing
• Optional: Addition of pepper

Below is a visual diagram showcasing the process of creating, storing and comparing hashes during a typical login process.

flowchart TD
    A[User Password: 'mypassword123'] --> B[Generate Unique Salt]
    B --> C[Salt: 'a8f5f167f44f4964e6c998dee827110c']

    D["Application-wide Pepper
    Stored in config/env"] --> E[Pepper: 'secretKey2024!']

    A --> F[Combine Components]
    C --> F
    E --> F

    F --> G["Combined String:
    'mypassword123' + 'a8f5f167f44f4964e6c998dee827110c' + 'secretKey2024!'"]

    G --> H["Hash Function
    Argon2id/bcrypt/scrypt"]

    H --> I["Final Hash:
    '$argon2id$v=19$m=65536,t=2,p=1$...$...'"]

    I --> J[Store in Database]
    C --> J

    J --> K[("Database Record:
    username: 'john'
    salt: 'a8f5f167...'
    hash: '$argon2id$v=19...'
    Note: Pepper NOT stored")]

    L[Login Attempt] --> M[Retrieve Salt from DB]
    M --> N[Get Pepper from Config]
    L --> O[User enters password]
    O --> P["Reconstruct:
    password + salt + pepper"]
    N --> P
    P --> Q[Hash with same function]
    Q --> R{Compare Hashes}
    K --> R

    R -->|Match| S[Authentication Success]
    R -->|No Match| T[Authentication Failed]

    class C primary
    class E purple
    class I warning
    class K info
    class L,M,N,O process
    class S success
    class T danger

Hash Storage in Practice

Now that we established what hashing and salting is, it becomes quite obvious why companies store the hash of your password and not the actual password.

When a user logs in anywhere, the input password they type gets hashed and then compared to the stored hash value. If they are the same, the login attempt is approved.

This is why when password databases get hacked, the attackers only obtain the hash values of your password and often the salt value. There are benefits to storing salt values separately from the passwords in such cases but since knowing the salt value does not change the security, it is often stored together with the password.

Modern Hashing Algorithms

Here is a quick comparison of some common modern hashing algorithms.

For example, if a bcrypt verification takes $50-100ms$, that should be acceptable for a user attempting to login once. However, an attacker who has to compute millions of hashes faces a different reality:

• User experience: $100ms$ delay = barely noticeable
• Attacker cost: $100ms \times 1,000,000$ attempts = $27.8$ hours for 1 million guesses
• Compare to MD5: Same 1 million guesses = $0.02$ seconds

The attacker’s time increases by a factor of 5 million while user impact is negligible.

This is because cracking time can be expressed as the following:

Real-world cracking speeds (RTX 4090 GPU):

This is why “computational cost” matters more than algorithm complexity. Also specialised hardware like ASIC miners can be 100x faster for certain algorithms.

User Behavior: The Human Factor

The reality of passwords is that no matter your password policy, users tend to follow similar patterns.

Analysis of these patterns shows that most “complex” passwords used by users still fall into some form of a template:

Below is a table that tries to show some commonly used patterns that most if not all users follow to some extent. This is just some examples of patterns used, in practice there are a lot more patterns than this, some even have the appearance of “complexity” while offering no increase in security.

Now that we’ve seen some patterns, the table below shows the real world impact these policies have on your user base and security level.

The Business Impact

We’ve seen that the theoretical security vs practical security are two totally different values.

While I understand that this may seem like an exaggerated or extreme example, it’s unfortunately how a large portion of users behave to some extent. I am yet to meet a single individual who has not used some form of patterns, rotations or other manipulations to their passwords. In the early 2000s, I was guilty of this myself but I did not know any better at the time.

The right password policy can not only help your security posture, it can also benefit your users by removing:

• Useless password rotations that do more harm than good
• Useless password complexity rules that add no measurable security

This way the user has less things to remember, they don’t have to recall unmemorable garbage of letters and symbols like Ax&2@kl2oP! and instead can remember simple sequence of words such as chickentanklettuce

Additionally, by not having to rotate these passwords every 30, 60, 90, 180 days or whatever else your policy suggests, the users are less likely to use patterns and/or rotations to their passwords.

Don’t get me wrong, I still think there is a place and time for password rotations, however the current implementations and policies are not doing it right.

None of this is new. NIST SP 800-63B addressed all of these points back in 2017 - deprecating forced rotation, dropping composition rules, and recommending length over complexity.

Password Policies That Actually Work

Let’s end with some practical and applicable recommendations that you can use immediately.

Note that I am not mentioning anything about their storage, salting or hashing. That’s because they do not affect the end user experience, however the importance of storage, salting and hashing cannot be understated.

My focus for this policy is both improving the security for the business while also improving the end user experience.

Disclaimer

Use the information provided here at your own risk, but if you find errors or issues in this guide, leave a comment and I’ll try to address them ASAP.