Common Password Attacks and Weaknesses

Weak passwords are passwords with low unpredictability they are common or structured in ways that make them easy for an attacker to guess. Instead of trying random combinations, attackers typically start with lists of common passwords, leaked credentials, and predictable variations.

123456, password, and qwerty are obvious examples. A more instructive example is Password1!. It satisfies many traditional complexity requirements — uppercase and lowercase letters, a digit, a symbol, and eight or more characters while remaining highly predictable. An attacker using a password dictionary or rule-based cracking strategy would likely try variations like this very early.

This is exactly why composition requirements alone don't guarantee password strength. A policy can force users to add uppercase letters, numbers, and symbols while doing very little to prevent predictable passwords.

A longer password or passphrase chosen from a sufficiently large and unpredictable space can provide substantially more resistance to guessing than a short password constructed to satisfy a checklist of character types.

Devices and administrative interfaces frequently ship with factory-set usernames and passwords such as admin/admin, admin/password, or root/toor. The problem arises when deployments leave those credentials unchanged, allowing anyone who knows the manufacturer's defaults to attempt authentication.

The Mirai botnet is a canonical real-world example. Mirai scanned the internet for vulnerable IoT devices and attempted authentication using a relatively small hardcoded list of known default Telnet credentials. It did not need a software exploit for these devices valid credentials were enough to gain access.

This makes default credentials particularly dangerous: the attacker doesn't need to discover a novel vulnerability when the correct password is already publicly known.

The basic mitigation is straightforward: require a unique credential to be established before the device or application can be used, rather than allowing factory credentials to remain active.

The application should prevent normal operation or administrative access until the default credential has actually been replaced.

Password policies can fail in two opposite directions.

Too weak: a policy with no meaningful minimum length or protection against commonly used passwords may allow credentials such as 1234 through outright.

Too rigid: overly complicated policies can encourage predictable behavior. Forced periodic rotation, for example, often leads users to make incremental changes such as:

Password1! → Password2! → Password3!

Each password technically satisfies the policy, but an attacker who knows the previous password can make a highly informed guess about the next one. Excessive composition requirements can also encourage users to write passwords down, reuse a single “complex enough” password, or make other predictable choices.

Modern guidance reflects this shift. NIST SP 800-63B recommends emphasizing password length, rejecting passwords that are commonly used or compromised, and avoiding arbitrary composition requirements. It also recommends against routine periodic password changes unless there is a specific reason to require them, such as evidence that a password has been compromised.

One practical approach is to check new passwords against a corpus of known-compromised passwords, such as the Have I Been Pwned Pwned Passwords dataset, rather than relying solely on rules like “one uppercase letter, one number, and one symbol.”

The goal isn't to make passwords look complicated. The goal is to make them difficult to guess and unlikely to have already been compromised.

Credential stuffing attacks reused credentials, not necessarily weak ones.

An attacker obtains a large collection of username-and-password pairs from a breach of one service and automatically tests those exact pairs against another application. For example, an attacker might obtain 10 million email:password pairs from an unrelated breach and submit those same credentials to the target application without modifying them.

The attack works because users frequently reuse passwords across multiple services. If a user's password was exposed in a breach elsewhere and they reused it on the target application, the attacker may gain access simply by replaying the stolen credential pair.

This is fundamentally different from password cracking. In cracking, the attacker attempts to discover the original password from a password hash or by guessing candidates. In credential stuffing, the attacker already has a candidate username and password and is testing whether that combination works somewhere else.

A strong password can still be a compromised password.

Defenses therefore need to address more than password storage: MFA, breached-password screening, rate limiting, bot detection, and monitoring for abnormal authentication patterns can all reduce the effectiveness of credential-stuffing attacks.

Password spraying is essentially the inverse of a targeted brute-force attack.

Instead of trying many passwords against a single account, an attacker tries a small number of common passwords against many different accounts. For example, an attacker might test a few highly predictable passwords across a large set of usernames, rather than repeatedly attacking one particular user.

The goal is to avoid triggering traditional per-account lockout thresholds. A conventional lockout policy might block an account after several consecutive authentication failures, but a spraying attack distributes those failures across many accounts. No individual account may receive enough failed attempts to trigger its lockout threshold.

Brute force: many passwords → one account
Password spraying: few passwords → many accounts

However, spraying is not inherently invisible. Defenses such as IP and network-level rate limiting, global authentication-failure monitoring, device and behavioral signals, breached-password screening, and detection of the same password being attempted across many accounts can identify the pattern even when per-account lockouts never activate.

A brute-force attack systematically attempts a large number of possible passwords against a target account, potentially exhausting the available password space until a valid credential is found.

Conceptually, the attack looks like this:

for password in candidate_passwords: 
      attempt_login(target_account, password) 

      if authentication_succeeds: 
            print("Credential found") 
            break

In a true exhaustive brute-force attack, candidate_passwords represents every possible combination within a defined character set and maximum length. In practice, attackers generally prioritize likely candidates first because the complete keyspace can become enormous as password length increases.

Online brute-force attacks are therefore highly sensitive to the defenses surrounding the authentication endpoint. Rate limiting, login throttling, account lockout, and detection of repeated authentication failures can make exhaustive online guessing impractical. These controls are covered as vulnerabilities in Lesson 3.4 and as defenses in Lesson 3.8

A dictionary attack is a more efficient form of password guessing. Instead of attempting every possible combination in the password space, the attacker starts with a curated list of likely passwords and tries those candidates first.

These lists can come from leaked-password datasets such as rockyou.txt, commonly used password collections, or wordlists tailored to a particular target. Target-specific lists might incorporate publicly known information such as an organization's name, product names, or other terminology associated with the target.

The approach works because human-chosen passwords are not distributed randomly across the possible password space. Users tend to choose familiar words, names, dates, patterns, and predictable combinations. A well-ordered candidate list can therefore find a password much faster than exhaustive brute force.

Brute force → systematically explores the password space.
Dictionary attack → prioritizes likely passwords based on human password-selection patterns.

This is also why password policies based solely on character composition can be misleading: Password1! may be vastly more likely to appear early in an attacker's candidate list than a longer, genuinely unpredictable password.

Password reuse occurs when a user uses the same password across multiple unrelated services. It is the key condition that makes credential stuffing effective.

The failure mode is a domino effect: if a password is exposed through a breach or compromise at one service, an attacker can try that same password against other services where the user has an account.

This means an application can have excellent security controls like strong password hashing, secure authentication code, rate limiting, and well-designed access controls and still be affected by a user's compromised password. The original credential exposure happened somewhere else, but the reused password allows that compromise to spread.

For example:

Service A: password is exposed in a breach
↓
Attacker obtains: user@example.com : compromised-password
↓
Service B: user reused the same password
↓
Credential stuffing: attacker replays the credential
↓
Service B account: compromised

Persistent login mechanisms allow users to remain authenticated across browser sessions. They are convenient, but they are also a separate authentication surface and are frequently mishandled.

A dangerous implementation might store the user's credentials directly in a long-lived cookie:

remember_token = base64(username + ":" + password)

Base64 is an encoding, not encryption. Anyone who obtains the cookie can trivially decode it and recover the user's actual password. The risk becomes even greater if the cookie is intercepted, copied from a compromised device, or exposed on a shared machine.

A secure implementation should instead generate a long, cryptographically random, unguessable persistent-login token. The server should store only a protected representation of that token and associate it with the relevant account and persistent-login record. This allows individual tokens to be revoked without requiring the user to change their password everywhere.

Persistent credentials should also have a limited lifetime, use appropriate cookie protections such as Secure, HttpOnly, and suitable SameSite settings, and ideally be rotated when they are used.

Sensitive actions such as changing a password, changing an email address, disabling MFA, or modifying recovery settings should require fresh authentication or another appropriate step-up verification.

“Remember me” should mean “restore a limited persistent session,” not “store my password and trust this device forever.”