How long to crack a password depends on the attack: a rate-limited login page, a stolen password hash and a reused password from another breach are different problems. Length matters, but randomness, storage method, attacker resources and whether the secret is already known can change the answer completely. A chart cannot give your account a universal safety countdown.［1］［2］

Key Takeaways

Online guesses face service controls; offline guesses against stolen hashes do not use the login page.

Credential stuffing tests previously exposed credentials instead of searching every possible password.

A length-and-character calculation assumes random choices; human patterns violate that assumption.

Use unique generated passwords, appropriate additional authentication and supported passkeys, while protecting recovery.

Which password cracking attack are you estimating?

Start by asking where guesses happen. An online attacker submits candidates to a service. The service can impose limits, detect abuse and require another authentication factor. NIST requires rate limiting for failed password attempts in the systems covered by its guidance.［1］ The exact implementation remains the service’s responsibility; seeing a login form does not tell you its full controls.

An offline attacker instead obtains password hashes and attempts candidate calculations on their own equipment. They compare a computed result with the stolen verifier. A login-page lockout does not limit that computation, because no login request is involved. The choice and configuration of password hashing therefore affect the cost of offline guessing.［2］

Credential stuffing is different again. The attacker takes credentials exposed elsewhere and tries them against another account. OWASP describes password reuse as the central opportunity in this attack.［3］ If the submitted secret is already correct, a large theoretical search space offers little help. A long password reused across services can still expose the other accounts.

Attack	What the attacker needs	What constrains it	Main personal response
Online guessing	An account identifier and a reachable login	Service limits and authentication controls	Strong unique secret and additional authentication
Offline guessing	A stolen password verifier	Hashing cost, guessing strategy and resources	Random length; service storage quality also matters
Credential stuffing	Exposed credentials from another source	Whether they are reused and other login controls	A different secret for every account

Phishing, malicious software and stolen sessions can bypass the question of brute-force time entirely. The limits of VPN protection against hackers distinguish network protection from account compromise. A private connection does not turn an already disclosed password into a secret again.

How do password length and randomness change the search space?

For an idealised password with L independently and uniformly selected characters from an alphabet of size A, the number of possibilities is A raised to L. That is a model of generation, not an estimate obtained by merely looking at a password’s appearance. A sentence selected because it is memorable does not necessarily have the same distribution as random characters.

Suppose a fictional generator chooses each of eight characters uniformly from 26 lowercase letters. Its space contains 26⁸, or 208,827,064,576, combinations. Two extra characters multiply that space by 26², or 676. These numbers illustrate exponential growth; they are not a recommendation to use eight characters, a measurement of any service or a claim about real cracking hardware.

If an attacker exhaustively searches a uniformly random space without repeats, the expected position is approximately halfway through it. An upper-bound full search and an average search are therefore different figures. Neither tells you where one particular secret happens to fall. An attacker can also prioritise likely candidates rather than enumerating combinations in a simple order.

Human choices make that last point crucial. A predictable phrase with a capital letter, a familiar year and a final symbol may look varied but follow a recognisable pattern. Adding one symbol to a compromised password does not create an independent random secret. Length helps most when the added material is not simply another predictable part of the same pattern.

A randomly generated passphrase can also be modelled, but you need the word-list size, the number of independently selected words and the generation method. A quotation chosen by a person does not inherit the search space of a random word generator. Do not convert word count into a strength claim without explaining where the words came from.

Why do password hash cost and hardware change the time?

Hashing is not the same as reversible encryption. A password verifier lets the service check a submitted secret without storing it as ordinary plaintext. For password storage, the calculation should make guesses costly enough to resist offline attacks while still permitting legitimate logins. OWASP discusses specialised password-hashing methods and configurable work factors.［2］

A salt distinguishes password-hash calculations even when people choose the same password. It frustrates reuse of one precomputed lookup across many accounts, but it does not add secret randomness to a weak password from the attacker’s point of view when the salt is available with the stolen data. Do not describe salting as a substitute for a good secret.［2］

The rate of guesses depends on the algorithm, its parameters, implementation and hardware. A headline based on one configuration cannot be transplanted to a different hash. More resources can increase throughput, but the improvement is not a universal multiplier independent of memory demands or other constraints.

This is why public research needs its method alongside the coloured cells. Hive Systems’ password table is an example of a published estimate tied to a stated methodology and computing assumptions.［4］ We do not reproduce its annual grid as a guarantee. Check the particular edition and method before comparing one cell with a claim about another system.

Ordinary users often cannot inspect how a service stores passwords. That uncertainty is a reason to use a strong unique secret and additional authentication, rather than assume the best possible storage. Service operators have a different task: assess the actual hashing configuration and migration policy against authoritative guidance, not against a consumer password-strength badge.

Can you calculate how long to crack a password?

In a deliberately simplified model, expected exhaustive-search time is roughly N divided by twice R, where N is the random search space and R is a constant number of guesses per second. The assumptions include independent uniform generation, no prior knowledge, no repeats and an unchanged rate. Remove those assumptions and the result may no longer describe the attack.

For the fictional eight-letter space above, an invented rate of 1,000 guesses per second gives an expected time of about 104,413,532 seconds, roughly 3.3 years. An invented rate of 1,000,000 per second gives about 104,414 seconds, roughly 29 hours. These rates are arithmetic inputs, not benchmarks for a real hash, GPU, login page or password. The examples are deliberately unsuitable as an account-safety prediction.

Calculation question	Required assumption	What remains unknown
How many possible secrets?	Alphabet or word list and independent random selection	Whether the person actually used that generator
How fast are guesses?	Specified hash, parameters and measured resources	The resources and strategy of a real attacker
What is the average time?	Search order and distribution	The position of a particular password
Is the account safe?	More than a cracking estimate	Recovery, phishing, reuse and session exposure

Online throttling and pauses make a constant-rate model particularly misleading for a live login. Conversely, an exposed password may be tested immediately through stuffing without exhausting any space. Before accepting a “centuries to crack” result, ask which problem the calculator models and which problems it excludes.

Never enter your actual current password into an unfamiliar calculator. Use a hypothetical example or a trusted tool’s documented local evaluation if needed. A score cannot compensate for disclosing the secret during the test. The model is useful for understanding why generation and length matter, without revealing an account credential.

What should you do instead of chasing a cracking-time score?

Use a unique generated password for each service, within its supported limits. Using a password manager with appropriate safeguards can make that practical, but its own access and recovery deserve attention. NIST’s current guidance permits managers and autofill and sets different minimum lengths for single-factor passwords and passwords used as part of multi-factor authentication.［1］ These are verifier requirements in a particular standard, not a promise that reaching a minimum makes every account secure.

For important accounts, enable suitable additional authentication and keep its recovery methods under your control. OWASP includes multi-factor authentication among defences against credential stuffing.［3］ Different methods resist different attacks; approving an unexpected prompt or handing a code to an impostor can still undermine protection. Prefer a supported phishing-resistant option where appropriate.

Passkeys change the authentication mechanism rather than merely extending a password. FIDO explains their public-key approach and phishing resistance.［5］ When supported, evaluate device access, synchronisation and recovery as well as the sign-in experience. A fallback password or compromised recovery route may remain part of the account’s security.

If your Wi-Fi settings brought you to a cracking chart, distinguish the Wi-Fi credential from the service account. WPA2 versus WPA3 explains how the authentication method changes the wireless context. A website’s hashing benchmark cannot be assumed to describe a router’s authentication exchange.

Our VPN account password guide addresses that specific account context, while when to change passwords focuses on replacement triggers. Here the decision is how to generate and separate secrets, rather than applying a fixed rotation schedule because a chart changed colour.

How should you respond when exposure is suspected?

If you have evidence a password was exposed, replace it through the service’s trusted route and address accounts where it was reused. NIST distinguishes evidence-based replacement from requiring periodic changes without a compromise indication.［1］ Do not wait for a theoretical estimate to expire before responding to a known disclosure.

Review recovery details and active sessions where the service provides those controls. Replacing a password does not universally revoke every existing session or fix an altered recovery address. If a device may be compromised, use a trusted device for recovery and address that separate problem. The exact controls depend on the service.

Protect your main email because it may be a recovery path for other accounts. Keep a record of the actions taken without recording the new secrets in an ordinary incident note. The wider digital privacy guide connects account response with device and data exposure. A useful response follows the actual route of compromise instead of treating all incidents as brute force.

For how attackers actually run these guesses against a login page, see what a brute force attack is.

Summary

Identify online guessing, offline hashing or credential stuffing before reading a time estimate.
Require generation, hashing, hardware and search assumptions behind a number.
Use unique random secrets and suitable additional authentication or passkeys.
Respond to evidence of exposure; a calculator is not an incident-response clock.

FAQ

How long does it take to crack a password?

There is no universal time. The answer depends on the attack, randomness, hashing cost and resources; a known reused secret may be tried without searching a large space.［2］［3］

Is a long password always safe?

No. Predictable text, reuse, phishing or an exposed session can defeat the purpose of length. Random generation and a different secret for each service address different parts of the problem.

Do symbols matter more than length?

Neither can be judged independently of generation. A larger random alphabet expands the space, but a predictable symbol added to a familiar phrase does not make the whole choice uniform.

Does a salt stop password cracking?

No. It separates hash calculations and reduces precomputation reuse, but an attacker with the salt and hash can still test candidates. The password and hashing cost remain important.［2］

Does a login lockout stop offline guessing?

No. Offline guessing uses stolen verifiers on the attacker’s equipment rather than the login page. Service throttling is relevant to online attempts and does not cap that separate computation.［2］

Should I change every password on a fixed schedule?

Do not use a cracking chart as a rotation calendar. Follow applicable account requirements and replace exposed or reused secrets; NIST’s guidance rejects mandatory periodic changes without compromise evidence.［1］

Do passkeys remove every account risk?

No. They provide a different, phishing-resistant authentication mechanism, but device access, recovery and fallback methods still matter. Evaluate the account’s full access path rather than only its main sign-in method.［5］

Sources:

NIST — SP 800-63B-4: https://pages.nist.gov/800-63-4/sp800-63b.html
OWASP — Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
OWASP — Credential Stuffing Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html
Hive Systems — Password Table research: https://www.hivesystems.com/blog/are-your-passwords-in-the-green
FIDO Alliance — Passkeys: https://fidoalliance.org/passkeys/

Sources checked 5 October 2026.

How Long Does It Take to Crack a Password?