Why Your Signup Form Is Less Secure Than You Think (And How to Fix It)

Eden — Wed, 08 Apr 2026 04:22:00 +0000

You've seen those password rules. "Must be more than 8 characters. Must include a symbol. Must contain a number." They have good intentions, but have one fatal flaw. Us.

You would hope everyone uses something more than "P@ssword1" (or any of its many variants), but unfortunately, you'd be wrong.

Photo of the Bastion Demo that shows the password: "P@ssword1" being included in 442,781 known breaches.

So what is actually happening, and what can we do about it?

These "traditional" password rules weren't wrong to exist, but they focus on the wrong thing. Primarily, they focus on what makes a password look complex, rather than what a machine considers "complex".

That'd be fine, except most attacks don't work that way. Most passwords susceptible to this are brute forced, rather than recreated from over your shoulder.

NIST (the National Institute of Standards and Technology) actually updated their guidelines recently, recommending longer minimum lengths and preventing the use of common, expected and compromised passwords.

Most people, understandably (my younger self included), took shortcuts, prioritising short, simple passwords (usually for memorisation) over complexity.

Now databases are littered with these "valid", but trivial passwords that can take machines minutes, if that, to crack (obviously this is still better than NO rules... "123456" has been found an embarrassingly large number of times in breaches).

Photo of the Bastion Demo that shows the password: "123456" being included in 209,972,844 known breaches.

What we actually want to measure is the complexity of guessing (or brute forcing) said password, which is a very different problem.

zxcvbn (I only just realised now, while writing this, that it's the bottom row of the QWERTY keyboard... never clicked when I was using it for the API ;-;) was built by Dropbox and takes a very different approach to password strength. Rather than checking for these rules, it uses more complex pattern matching to estimate the number of guesses it would take to crack a password.

zxcvbn checks against things like:

Most common passwords, names, and dates
Keyboard patterns (qwerty, 123456, and even zxcvbn)
Common substitutions (@ for a or 3 for e)
Repeating/reversed characters or strings (aaabbbccc)

The result is a score, crack times against multiple scenarios (throttled online, offline fast hash, etc.), as well as warnings and suggestions for weaker passwords.

Bad password example:

Photo of the Bastion Demo that shows the password: "P@ssword1" being included in 442,781 known breaches. It also shows the estimated crack time ranging from 4 days to less than a second. Below that is a warning with a list of suggestions.

Good password example:

Photo of the Bastion Demo that shows the password: "correct-horse-battery-staple" being included in no known breaches. It also shows the estimated crack time ranging from centuries to 57 years.

In Practice:

Here's what it looks like to actually check a password against an API that uses zxcvbn:

Request:

POST https://bastion.eande171.workers.dev/v1/evaluate 
BODY { "password": "P@ssword1" }

Response:

{
    "score": 1,
    "strength": "Weak",
    "entropy_bits": 13.425215903299385,
    "crack_times": {
        "online_throttled": "4 days",
        "online_unthrottled": "18 minutes",
        "offline_slow_hash": "1 second",
        "offline_fast_hash": "less than a second"
    },
    "warning": "This is similar to a commonly used password.",
    "suggestions": [
        "Add another word or two. Uncommon words are better.",
        "Capitalization doesn't help very much.",
        "Predictable substitutions like '@' instead of 'a' don't help very much."
    ]
}

This response gives you a lot of information to work with. The score and strength fields give you a numerical and human-readable version of the password strength.

An attacker with throttled attempts would find this password in 4 days (likely because the form would start rejecting too many attempts). This drops to 18 minutes without any throttling, and if they got access to the database, they could calculate it in no time at all.

The warning and suggestion fields are an addition given to weak passwords to give users clear, actionable feedback to improve the quality of their passwords.

This can be compared to a password (or passphrase), which is just a little bit longer:

Request:

POST https://bastion.eande171.workers.dev/v1/evaluate 
BODY { "password": "correct-horse-battery-staple" }

Response:

{
    "score": 4,
    "strength": "Very Strong",
    "entropy_bits": 64,
    "crack_times": {
        "online_throttled": "centuries",
        "online_unthrottled": "centuries",
        "offline_slow_hash": "centuries",
        "offline_fast_hash": "57 years"
    },
    "warning": null,
    "suggestions": null
}

This fills me with much more confidence, knowing that even if someone did get access to a database, it would take them 57 years (or possibly centuries) to crack it (unless it's stored in plain text... but that's a separate issue- although just as bad).

Password rules certainly aren't useless, but genuine protection requires measuring complexity, not enforcing arbitrary rules. zxcvbn (still can't believe I didn't get that) gives you a way to do that without reinventing the wheel.

Unfortunately, this is only one half of the problem... what happens if a password is strong but is already in a breach? It's more common than you think.

If any of you made it to this bit... THANK YOU!!! If you want to poke around the API I made for this exact purpose, you can find it here. It would really mean a lot if you could check it out (even just the free/demo versions).

DEV Community: Eden

Why Your Signup Form Is Less Secure Than You Think (And How to Fix It)

In Practice: