DEV Community

Cover image for How to Check Password Strength: Entropy, Crack Time, and What Developers Should Know
MahaVault
MahaVault

Posted on

How to Check Password Strength: Entropy, Crack Time, and What Developers Should Know

We have all seen passwords that look secure:

P@ssw0rd123!

Uppercase letter.

Lowercase letters.

Numbers.

Special characters.

It checks all the boxes people often associate with a "strong password."

But is it actually strong?

That's a more interesting question.

Password strength isn't determined simply by how complicated a password looks. Length, randomness, predictability, password reuse, and the way a system stores passwords all matter.

If you want a quick way to evaluate a password, MahaVault's Password Strength Checker provides an entropy score and estimated crack time directly in your browser.

Try it here:

https://www.mahavault.com/tools/password-strength-checker

What Does Password Strength Actually Mean?

Password strength is essentially about how difficult it is for an attacker to discover a password.

A password becomes harder to guess when the attacker has to consider a very large number of possible candidates.

This is where randomness and length become important.

Consider:

Password123!

It contains several character types, but the underlying structure is extremely familiar.

Now consider a randomly generated credential:

v7$Kp2!xQ9#mL4@z

The second example doesn't rely on a common word or an obvious human-created pattern.

The difference isn't simply the presence of symbols.

It's the unpredictability.

What Is Password Entropy?

Entropy is commonly used to represent the uncertainty associated with a password.

For a theoretical password generated uniformly from a character set of size "N" with length "L", the maximum entropy can be represented as:

L × log₂(N)

For example, if a password generator chooses every character independently from a defined set, increasing the length increases the theoretical number of possible combinations.

The important word here is theoretical.

Real-world password security can be affected by how the password was generated and how the authentication system processes it.

A human-created password usually doesn't achieve the theoretical maximum simply because it contains characters from several categories.

Why Character Variety Isn't Enough

A common password policy might require:

  • One uppercase letter
  • One lowercase letter
  • One number
  • One special character

Those requirements can be useful, but they don't guarantee randomness.

Consider:

Summer2026!

It satisfies many traditional password rules.

But the structure is predictable:

Common word
+
Year
+
Special character

An attacker doesn't necessarily need to try every possible combination of characters.

They can prioritize common words, patterns, dates, substitutions, and previously observed password structures.

This is why password strength should not be reduced to a checklist of character types.

Password Length Matters

Length has a major impact on the number of possible combinations.

Suppose a password is generated uniformly from a character set of size "N".

The number of possible passwords of length "L" is:

N^L

Adding another character multiplies the theoretical search space by "N".

This is one reason longer passwords can provide a substantial security advantage.

However, length alone doesn't solve everything.

A long password based on a common phrase may still be predictable.

For example:

ThisIsMyVeryLongPassword2026!

is long, but it follows a human-created pattern.

A randomly generated password or randomly selected passphrase is generally a better approach.

What Is Estimated Crack Time?

Many password strength tools provide an estimated crack time.

This is useful, but it is important to understand what the number means.

It is an estimate based on assumptions about how an attacker might attempt to recover the password.

It isn't a guarantee that:

"Nobody can crack this password for the next 100 years."

Different attack scenarios can produce very different results.

For example, an attacker might use:

  • Brute-force attacks
  • Dictionary attacks
  • Password lists
  • Credential stuffing
  • Pattern-based guesses
  • Information about the target

The password hashing algorithm and its configuration also matter when passwords are being attacked offline.

So crack time is best treated as an indicator rather than an absolute security prediction.

Password Hashing Changes the Equation

Developers also need to distinguish between attacking a password directly and attacking a stored password hash.

A properly designed authentication system should not store plaintext passwords.

Instead, passwords should be processed using an appropriate password hashing function.

Modern password hashing approaches are designed to make large-scale password guessing more expensive.

That means password strength and password storage are connected, but they are not the same problem.

A strong password stored incorrectly can still create serious risk.

A secure password-hashing implementation cannot magically make a weak password strong either.

Both sides matter.

Password Reuse Is Another Problem

Even a very strong password becomes a liability if it is reused across many services.

Imagine using one password for:

Git hosting
Cloud provider
Email
Database
Project management
SaaS applications

If that password is compromised somewhere, attackers may attempt it against the other services.

This is why every important account should have a unique credential.

How to Check Password Strength

A password strength checker can be useful as a quick sanity check.

MahaVault's Password Strength Checker provides:

  • Entropy score
  • Estimated crack time
  • A simple way to evaluate password strength

You can try it here:

https://www.mahavault.com/tools/password-strength-checker

The goal isn't to obsess over one number.

The goal is to understand whether the credential you're considering is based on a weak or predictable pattern.

A Better Password Workflow

For developers and security-conscious users, a practical workflow looks like this.

Generate Instead of Invent

Don't spend five minutes trying to invent a clever password.

Use a secure password generator when the credential doesn't need to be memorized.

Make It Unique

Don't reuse credentials between unrelated services.

Use Sufficient Length

Prefer longer credentials where the service supports them.

Check Suspicious Passwords

If you're unsure whether something you've created is strong enough, use a password strength checker as an additional sanity check.

Store Credentials Securely

Don't put passwords in:

Source code
Git repositories
Plain-text files
Application logs
Screenshots

Use appropriate credential and secret-management practices.

Enable MFA

For important accounts, use multi-factor authentication when available.

A Note About Checking Real Passwords Online

There is an important privacy consideration when using password-strength websites.

Never assume that entering a password into a website is automatically safe.

Before testing a sensitive credential, understand how the tool processes the input.

For a production password or an actively used credential, a local or offline checker is preferable when available.

A password-strength tool should help you understand password security without creating a new security problem.

Try MahaVault's Password Strength Checker

If you want a quick way to evaluate password strength, try the MahaVault Password Strength Checker:

https://www.mahavault.com/tools/password-strength-checker

It provides an entropy score and estimated crack time, giving you more information than simply looking at whether a password contains numbers and symbols.

The bigger lesson is simple:

Don't judge a password by how complicated it looks.

Look at length.

Look at randomness.

Look at predictability.

And most importantly, don't reuse it.

What do you normally use to evaluate password strength in your development workflow?

webdev #security #tools #javascript

Top comments (0)