How passwords are attacked · 4 min read

Phishing and passwords: why strength doesn't help

Phishing does not guess passwords; it asks for them. Strength is irrelevant to it, which is why defenses focus on where the password is entered.

Every other guide in this section is about guessing: how many tries an attacker needs, and how storage and length change that. Phishing is different. It does not guess. It presents a convincing imitation of a login page and waits for the real password to be typed into it. NIST SP 800-63B-4 is blunt about the consequence: “Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy and complex passwords as they are on simple ones.”

How a phishing page gets a password

The pattern is simple:

1. A message, advertisement or search result leads to a page that looks like a real service’s sign-in page.
2. The page sits at an address that is not the real service, but resembles it.
3. The person enters their username and password. The page records them, and often forwards them to the real service immediately so that the login appears to work.

NIST defines the problem in terms of an “impostor verifier,” a fake that poses as the real service, and notes that how the person got there does not matter: “regardless of whether the claimant was directed there via search engine optimization or prompted by email, it is considered to be a phishing attack.”

Worked example: strength versus one submission

Take a six-word passphrase from the EFF list: 6 × 12.925 = 77.55 bits. On the site’s illustrative rates (assumptions for scale, not measurements), guessing it would take on average:

• about 35,000 years against a fast, unsalted hash at 10^11 guesses per second
• about 350 billion years against a slow hash at 10,000 guesses per second

A phishing page needs one submission. The attacker does not have to search 2^77.55 possibilities, because the person hands over the one that works. The same is true of 123456. Against phishing, the two have the same strength.

That is not an argument against strong passwords. A strong, unique password still protects against guessing, breaches and credential stuffing. It means phishing needs a separate defense.

Look-alike addresses

The part of a phishing attack people can check is the address. Imitations rely on details that are easy to miss:

• Similar spelling: examp1e.com (digit one) instead of example.com, or an extra word such as example-login.com.
• The real name in the wrong place: example.com.account-check.net belongs to account-check.net; the registered domain is the part just before the final suffix.
• Look-alike characters from other alphabets: Cyrillic small letter a (U+0430) renders almost identically to Latin small letter a (U+0061). A domain written with the Cyrillic letter is a different domain; in its encoded form, exаmple.com with a Cyrillic а becomes xn--exmple-4nf.com.

People are not reliable at catching these, especially on a phone. That is why the stronger defenses take the decision away from human eyes.

Why one-time codes are not enough

A second factor helps against stolen passwords in general, but codes typed by hand can be phished the same way passwords are. A time-based one-time password (TOTP, RFC 6238) changes every time step, by default 30 seconds. A phishing page that forwards the code to the real service while it is still valid succeeds. NIST says so directly: authenticators “that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated.”

Codes still raise the bar. They expire, and the attacker must relay them live instead of storing them for later. See how authenticator apps work.

What phishing resistance means

NIST defines phishing resistance as “the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier … without relying on the vigilance of the claimant.” The last phrase is the key: it must work even when the person is fooled.

It recognizes two methods:

The W3C Web Authentication standard is NIST’s example of verifier name binding. It defines public key credentials that are each “scoped to a given WebAuthn Relying Party,” meaning a specific site. A credential registered at example.com is simply not offered at examp1e.com. Passkeys are built on this standard; see passkeys explained.

Where passwords fit

Passwords themselves cannot be phishing-resistant: a person can always type one into the wrong page. Two things narrow the risk:

• Autofill that matches the domain. A password manager, whether the one built into your browser or operating system or an open-source one, generally offers a saved password only on the site where it was saved. If it does not offer to fill on a page that claims to be that site, the mismatch is a useful signal. NIST requires services to “allow the use of password managers and autofill functionality.” See password managers explained.
• Uniqueness. A phished password that is unique opens one account. A reused one opens every account that shares it.

Note: A phishing page can collect anything typed into it, including answers to security questions and recovery codes. Strength protects against guessing; it does not protect against disclosure.

Summary

• Phishing collects passwords as they are typed, so length and randomness make no difference to it.
• Look-alike domains are hard to spot reliably by eye.
• Typed one-time codes can be relayed within their time window; NIST does not count them as phishing-resistant.
• Phishing resistance comes from credentials bound to the real site’s name or to the connection, as in WebAuthn and passkeys.
• Domain-matched autofill and unique passwords limit what a successful phish can reach.

General explanation, not advice for a particular situation. Updated 2026-10-31.