Everything About Passwords

Introduction: Are Most Password Policies Just Bad?

If you’ve worked in IT or security for more than five minutes, 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?

• 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
• Password sharing for shared SaaS accounts
• Password reuse across multiple accounts (everyone does this)
• Sending passwords through Slack, Teams, email, or sticky notes

Here’s the thing: most of these policies were created by people who’ve never had to actually implement secure authentication systems or deal with the business reality of user behavior. They 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 behavior.

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 or the size of the character set increases the entropy and thus the password strength.

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: Forced Length (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 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)

The Reality of Offline vs Online Attacks

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.

Online vs Offline: The Critical Distinction

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

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)"]

    classDef inputChanged fill:#854d0e,stroke:#fbbf24,stroke-width:2px
    classDef outputDifferent fill:#9a3412,stroke:#fb923c,stroke-width:2px

    class F inputChanged
    class I outputDifferent

We can more generically visualise this process as inputing 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
    SHA-256"]
    B --> C["Fixed Size Output
    256-bit digest
    64 hex characters"]

What is Salting?

These salt values are often stored together with that 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..."]

    classDef saltHighlight fill:#0c4a6e,stroke:#38bdf8,stroke-width:2px

    class C saltHighlight

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)"]

    classDef salt1 fill:#0c4a6e,stroke:#38bdf8,stroke-width:2px
    classDef salt2 fill:#134e4a,stroke:#5eead4,stroke-width:2px
    classDef hash1 fill:#713f12,stroke:#fbbf24,stroke-width:2px
    classDef hash2 fill:#7c2d12,stroke:#fb923c,stroke-width:2px

    class B salt1
    class B2 salt2
    class E hash1
    class E2 hash2

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 atleast 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]

    classDef saltNode fill:#0c4a6e,stroke:#38bdf8,stroke-width:2px
    classDef pepperNode fill:#701a75,stroke:#d946ef,stroke-width:2px
    classDef hashNode fill:#713f12,stroke:#fbbf24,stroke-width:2px
    classDef dbNode fill:#1e3a8a,stroke:#60a5fa,stroke-width:2px
    classDef loginNode fill:#065f46,stroke:#34d399,stroke-width:2px
    classDef successNode fill:#14532d,stroke:#4ade80,stroke-width:2px
    classDef failNode fill:#7f1d1d,stroke:#f87171,stroke-width:2px

    class C saltNode
    class E pepperNode
    class I hashNode
    class K dbNode
    class L,M,N,O loginNode
    class S successNode
    class T failNode

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 logins 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 datababses 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.

Most Companies Still Stuck in 2000s-Era Rules

NIST SP 800-63B (2017) changed their password guidelines and yet most policies and security experts still recommend things that are outdated and ineffective.

1. Password expiration is DEAD

The old recommendation of forced password change every 30-90 days is no longer acceptable.

It shouldn’t be recommended at all, yet most companies still have 90 day expiration everywhere.

2. Composition rules - Mostly DEAD

Silly complexity rules of uppercases, lowercases, numbers, symbols should be gone. Yet they are everywhere.

Another example of completely outdated and ineffective measures having widespread usage.

3. Length over complexity

Most minimum length for password is still 8 characters, yet we’ve shown how ineffective they are in practise.

In my opinion, it is completely unacceptable to have passwords with less than 16 characters and current minimums of 8-12 are still widely accepted.

Most of my passwords start at minimum 20 characters and yet so often there are arbitrary limits imposed on passwords such as they cannot be longer than 20-24-32 etc characters.

4. Breach Detection

It’s quite simple and easy to check whether certain passwords have been detected in previous breaches. Yet most policies have no guidelines about doing compromised password detection.

All of these points above have already been addressed by NIST in 2017, yet we are in 2025 and most of these are not adopted or even used at all.

Password Policies That Actually Work

We’ve covered a lot of information regarding passwords and their security. We’ve also seen how ineffective or outdated most password recommendations and policies are.

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 since that does not affect the end user.

Red Flags: When Your Security Consultant Doesn’t Know What They’re Doing

Notes

Organizations continue enforcing 90-day password rotations and complexity requirements despite NIST deprecating these practices in 2017. The disconnect exists because security decisions are made by people who don’t understand entropy calculations or real-world attack vectors. If your security consultant recommends SHA256 for password storage or can’t explain why length beats complexity, find someone who can. The gap between correct password practices and actual implementation is where most breaches happen.

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.