Password Security

Cybersecurity / 11 Sep 2026 / 9 min read

Bound Password Verification Work to Resist Resource Exhaustion

Password hashing is intentionally expensive. That cost makes each offline password guess more expensive after a verifier database is stolen. The same property creates an operational risk on a live login endpoint: an unauthenticated client can ask the server to perform costly password verification again and again. A service that treats every login attempt as unlimited work can exhaust CPU, memory, worker slots, or downstream capacity before an attacker needs a valid account. The defensive goal is not to make password hashing cheap. It is to preserve a suitable password-hashing cost while placing firm limits around how much verification work the service will accept at once.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 8 min read

Use Password Managers as a Phishing Signal

A phishing page can copy a real login screen closely enough that visual inspection is unreliable. The logo, wording, colours, and layout may all look familiar while the page is hosted somewhere the legitimate service does not control. If a user types a password there, the look of the page has done nothing to protect the credential. A password manager can add a different kind of signal. Instead of deciding from appearance alone, it can associate a saved credential with the website where that credential belongs and offer it only when its matching rules are satisfied. When a familiar login page appears but the expected credential is not offered, that mismatch can be a reason to stop and inspect the destination before entering anything.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 10 min read

Rate Limit Login Attempts Without Creating Easy Lockouts

A login endpoint has to accept wrong passwords. Users mistype them, password managers can hold stale credentials, and old devices sometimes retry automatically. An attacker can use the same interface to make thousands of guesses unless the application limits how quickly authentication can be attempted. The obvious fix is to lock an account after several failures. That slows guessing, but it creates another problem: anyone who knows a username may be able to keep that user locked out by deliberately submitting bad passwords.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 10 min read

Rate Limit Login Attempts Without Creating a Lockout Weapon

A login endpoint has an awkward property: before authentication succeeds, it must accept requests from people whose identity it hasn’t proved yet. That makes it a natural target for automated password guessing. If the endpoint allows unlimited attempts, an attacker gets unlimited opportunities to try credentials. If it permanently locks an account after a few failures, the attacker may be able to lock out the legitimate user instead. Login rate limiting is the middle ground. It reduces how quickly repeated authentication attempts can be made, but the design matters. A useful limiter needs to constrain attacks aimed at one account, attacks coming from one source, and distributed attacks without turning every false positive into a long outage.

Cybersecurity Authentication

Cybersecurity / 07 Sep 2026 / 8 min read

Verify the Entire Password Without Truncation

A password field may accept 100 characters while the authentication system verifies only the first 72, 64, or 20. The interface appears to accept the whole password, but the security decision does not. That mismatch is password truncation: silently discarding part of a password before storing or verifying it. Truncation can make two visibly different passwords authenticate as the same credential. It can also create confusing migration bugs when one component preserves the full password and another shortens it.

Cybersecurity Authentication

Cybersecurity / 07 Sep 2026 / 10 min read

Let a New Password Reset Request Supersede Older Ones

A password reset link is temporary authority to replace an account credential. If a user requests three reset emails and all three links remain valid, the application has created three independent pieces of recovery authority. Using one link may not remove the risk from the other two. That matters because reset messages can remain in inboxes, mail previews, browser history, or other places the application does not control. A user may request a second link because the first message arrived late, looked stale, or was requested by mistake. If the second request leaves the first token valid, the user’s attempt to start over has not actually replaced the earlier recovery path.

Cybersecurity Authentication

Cybersecurity / 06 Sep 2026 / 11 min read

Rate-Limit Login Attempts by Account and Source

A login endpoint may verify passwords correctly and still give an attacker too many chances to guess them. If failed attempts can be repeated quickly, weak or reused passwords become easier to test through the same interface legitimate users use. A common response is to add a rate limit. The difficult part is choosing what the limit follows. Limiting only an IP address misses distributed attempts from many sources. Limiting only an account lets one source spread attempts across many accounts. Combining the IP address and account into one key looks stricter, but creates a fresh allowance for every pair.

Cybersecurity Authentication

Cybersecurity / 05 Sep 2026 / 7 min read

Use a Pepper to Limit Offline Password Cracking

A strong password-hashing function protects stored passwords by making each password guess deliberately expensive. A unique salt ensures that equal passwords do not produce reusable precomputed results. But if an attacker steals the entire password database, the salts are normally there too. The attacker can still test guesses offline without contacting the application. A pepper adds a different kind of barrier: a secret value used when deriving or protecting password verifiers, but stored separately from the password database. If an attacker obtains only the database and not the pepper, the stolen hashes are less useful for offline guessing.

Cybersecurity Password Security

Cybersecurity / 05 Sep 2026 / 9 min read

Store Passwords for Offline Attack Resistance

A login system needs to recognize a password later, but it does not need to recover the original password. That distinction should shape how passwords are stored. If an application stores plaintext passwords, reversible encrypted passwords, or fast general-purpose hashes, a database disclosure can turn into a much larger authentication problem. An attacker who obtains password verifiers can make guesses on their own hardware, without sending each attempt through the application’s login endpoint. Online rate limits no longer control that work.

Cybersecurity Authentication

Cybersecurity / 05 Sep 2026 / 11 min read

Slow Down Automated Login Attacks

A password login endpoint has to accept attempts from people who sometimes mistype their passwords. The same property also gives automated clients a place to try many guesses. If the application processes every attempt at full speed, an attacker can repeatedly test passwords against one account or spread attempts across many accounts. A correct password hash does not solve this problem. Password hashing makes each password verification deliberately costly, but the server still has to decide how many online attempts it will accept. Without another control, the application may provide an attacker with a large number of guesses over time.

Cybersecurity Authentication

Cybersecurity / 05 Sep 2026 / 10 min read

Block Common and Compromised Passwords at Creation

A password can satisfy a length rule and still be a poor authentication secret. A familiar phrase, a predictable pattern, or a password exposed in an earlier breach may be among the first values an attacker tries against many accounts. This creates a practical problem for applications that allow users to choose passwords: checking only syntax does not tell you whether the chosen value is already widely known or unusually easy to predict.

Cybersecurity Authentication

Cybersecurity / 03 Sep 2026 / 10 min read

Store Passwords with Memory-Hard Hashing

A login system must verify passwords, but it should not need to recover them. That distinction matters when an authentication database is copied through a vulnerability, backup exposure, or operational mistake. If the database contains plaintext passwords, the compromise immediately reveals them. If it contains fast, unsalted hashes, an attacker can test large numbers of password guesses efficiently and reuse work across accounts. Password hashing changes the problem. The application stores a verifier produced by a deliberately expensive password-hashing function. During login, it applies the same function to the submitted password and checks whether the result matches.

Cybersecurity Password Security