Dictionary attacks: password guessing, account defenses and VPN limits

Cover: AI-generated editorial illustration of organizing plain cards beside a closed laptop in a lived-in sewing workshop; not a real customer, product screenshot or VPN test.

A dictionary attack is password guessing guided by likely choices: familiar words, common passwords and predictable variations. It describes a method, not a particular virus. The important question is where the guesses are checked. Attempts against a live sign-in page face that service’s controls; guessing against stolen password hashes happens outside its login page. A VPN does not repair either a predictable password or a stolen password database.

This guide explains the distinction for people protecting their own accounts. It provides no attack tools, password lists or instructions for trying anyone else’s credentials. We reviewed current NIST and OWASP documentation, rather than performing account attacks or measuring cracking times. Those sources support layered defenses, with responsibilities shared between account holders and service operators.

What dictionary attacks try to exploit

People often choose secrets that have meaning to them. A memorable word with a familiar ending may also be a predictable choice. An attacker does not need to enumerate every possible string before trying plausible candidates. That explains the term dictionary: the candidate collection can extend beyond an ordinary language dictionary to include previously common passwords and recognizable patterns.

Dictionary guessing belongs within the broader family of password-guessing attacks. Usage varies: OWASP describes brute force broadly enough to include guesses from dictionaries. Treating the labels as completely unrelated technologies obscures the practical issue. A secret that is easy to anticipate needs attention regardless of the label attached to an attempt.

Online guessing and offline guessing need different defenses

In an online attempt, a service receives authentication requests and can slow or refuse them. OWASP recommends login throttling and considers account lockout, while warning that poorly designed lockouts can deny access to legitimate users. Blocking an address alone is an incomplete strategy: the account and wider activity pattern also matter. A CAPTCHA can add friction, but it is another layer rather than proof that abuse is impossible.

Offline guessing becomes relevant when password-verification data is exposed. A correctly designed service stores password hashes rather than readable passwords. Guessing can then involve checking candidate values against that stolen data without submitting each attempt to the original website. Its login delay cannot regulate those separate calculations. The original breach and the later guessing are related events, but they are not the same thing.

OWASP’s storage guidance explains why a unique salt and a suitable slow password-hashing method matter. The salt makes shared precomputation less useful across accounts; it does not make a weak password unpredictable. Appropriate hashing raises the cost of guesses. These are service-operator responsibilities, and this article does not claim to inspect the storage implementation of any website or VPN provider.

A useful way to assess advice is to ask which boundary it changes. A sign-in delay affects online requests. Better password storage affects the consequences of a database exposure. A unique personal password limits reuse between services. None substitutes for the other two. Our data leak versus data breach guide provides related context for interpreting an incident notice.

Choose unpredictability and uniqueness over cosmetic rules

NIST’s current password guidance rejects mandatory mixtures of character categories and routine forced changes without evidence of compromise. It also requires covered verifiers to screen new passwords against commonly used, expected or compromised choices. That does not mean symbols are harmful or every word-containing passphrase is weak. It means satisfying a character checklist alone is an inadequate measure of a password’s resistance to guessing.

NIST’s explanatory appendix emphasizes length and the difficulty of estimating the strength of human choices. Adding length through a predictable expression is different from generating a long random secret. A password manager can make distinct credentials practical without requiring you to memorize each one. Protect the manager itself carefully, and consider its recovery process before depending on it.

Do not interpret advice against calendar-based rotation as permission to keep an exposed password. Evidence of compromise changes the decision. Equally, do not copy a sample password from any article, including a plausible-looking long example: once published, it is a shared example rather than your private secret. We deliberately provide no reusable password template.

Add authentication layers and keep recovery usable

OWASP recommends multifactor authentication against password-related attacks. Its value is that possession of the password alone need not complete sign-in. A second password or a personal trivia question is still knowledge, not an independent factor. Availability and enrollment details differ between services, so check the actual security settings offered by the account you use.

For planning, separate everyday sign-in from recovery. Record where the official recovery instructions are, how you would regain access after losing a device, and whether a backup method remains available. This is an organizational exercise; there is no reason to share passwords or recovery codes with a publisher, support impersonator or someone claiming to verify your protection. Avoid treating the presence of an MFA badge as a guarantee against every account-compromise route.

What a VPN does, and why it is a separate decision

A VPN changes how covered network traffic travels between your device and a VPN endpoint. It does not change the secret stored by a shopping site, generate stronger passwords merely by connecting, or stop someone elsewhere from submitting guesses. A VPN subscription is therefore not a necessary purchase for following this account-security guide.

If you also have an independent network-privacy need, read how a VPN works and the limits of VPN protection. Optional listings below concern that separate purpose. They are not dictionary-attack protection, password-manager endorsements or evidence that we tested account defenses. Compare the NordVPN review and provider store only if network privacy is part of your actual requirement; check current terms before purchasing.

Check current NordVPN offers and verification dates →

Check current NordVPN offers and verification dates →

A practical account-security worksheet

Start with a short inventory of important accounts, using account names rather than secrets. For each, note whether its password is unique, which additional authentication options are enabled, and where official recovery help is located. Prioritize accounts whose loss would obstruct recovery elsewhere. This lets you identify concrete gaps without uploading credentials to a third-party checklist.

If an incident notice arrives, navigate independently to the service’s known website or application. Determine whether the notice concerns an attempted login, an actual session or exposed stored data; those descriptions imply different questions. Follow that service’s recovery instructions, address affected reused credentials, and review unfamiliar sessions using its own controls. An unexplained alert is not enough to diagnose a dictionary attack, and changing your VPN endpoint is not a substitute for dealing with account access.

Advantages of this approach

The worksheet separates actions you control from controls operated by the service. It also prevents a network-privacy purchase from displacing account hygiene. A small, maintained record of recovery routes is more actionable than an impressive-looking claim that a particular password takes a fixed number of years to guess.

Limitations and reasons to seek further help

You cannot infer a site’s hashing quality from its appearance, and this document does not certify any service. An employer-managed account may have a dedicated incident process; use that process rather than changing shared controls yourself. If you cannot regain access, preserve the relevant notice and use verified support channels. The objective is a clear next step based on the actual account state, with no invented certainty about an attacker’s method.

Research note: This guide is based on current official documentation and editorial analysis. It is not a hands-on security test. Research details are retained privately under our editorial policy.