They don't always want your password.

#Necessary, but not sufficient

A strong, unique password defeats a specific and still-common set of attacks: credential stuffing with passwords leaked from other breaches, password spraying against weak defaults, and brute force. Those are real, and a password manager plus unique credentials shuts most of them down. Keep doing it.

The problem is treating that win as total. Authentication is not a wall you either climb or do not. It is a process that ends by issuing a token, a session cookie, an access token, a Kerberos ticket, that says "this person already proved who they are." Everything after login trusts that token. Many modern attacks simply target the token, or the systems that issue and honor it, and never engage the password at all.

#Stealing the session, not the password

When you log in, the service hands your browser a session token so it does not have to ask for your password on every click. That token is a bearer credential: whoever holds it is treated as you, no password and no second factor required, until it expires. Attackers who obtain that token, through malware that reads browser storage, or a phished session, replay it and are simply logged in as you. This is often called "pass the cookie."

#Real-time phishing that beats MFA

The technique that made "MFA solves phishing" obsolete is adversary-in-the-middle (AiTM) phishing. Instead of a static fake login page that only harvests a password, the phishing site is a live proxy sitting between the victim and the real service. The victim enters their password and completes MFA against the genuine site, through the proxy, and the attacker captures the resulting session token in transit. The login succeeds, the second factor is satisfied, and the attacker walks away with a valid session.

This is not exotic anymore; it is a well-documented, widely-tooled class of attack. It is also why "we enabled MFA" and "we are phishing-resistant" are different claims. Ordinary one-time codes and push approvals can be relayed in real time. Only certain kinds of MFA are built to resist it.

#Not all MFA is equal

MFA is a category, not a guarantee, and the categories differ enormously in strength:

• SMS one-time codes are the weakest common factor. They are phishable, and they are exposed to SIM-swap attacks, where an attacker convinces or bribes a carrier to move your number to their SIM and receives your codes directly.
• Authenticator app codes and push approvals are better, but still phishable through AiTM, and push approvals are vulnerable to "MFA fatigue," spamming a user with prompts until they tap approve to make it stop.
• Phishing-resistant MFA, FIDO2 security keys and passkeys, cryptographically binds the login to the real site's origin. A proxy on a look-alike domain cannot satisfy it, which closes the AiTM path by design.

#Consent, not credentials

In cloud and SaaS ecosystems, an attacker can gain lasting access without ever seeing a password by abusing OAuth. In an illicit consent attack, the victim is lured into approving a malicious third-party application's request for access to their account. The user authenticates normally to their real provider, then clicks "allow." The application receives a token scoped to read mail, files, or more, and that grant persists independently of the password. Changing the password later does not revoke it.

This is a password-free foothold by design. The defense is not stronger passwords; it is governing which applications may be consented to, and reviewing existing grants.

#Moving without a password at all

Inside a network, especially a Windows domain, authentication often uses tickets and hashes rather than raw passwords, and attackers abuse those primitives directly. Techniques in the pass-the-hash and Kerberos-abuse families let an attacker who has compromised one host reuse cached authentication material to move laterally, without ever knowing or cracking the underlying password. To the systems involved, the access looks legitimate, because it uses the same tokens legitimate access uses.

The lesson is the same one, at the network layer: once you hold the artifact that proves identity, the password is irrelevant. This is why credential hygiene, tiering, and least privilege matter as much as password strength.

#Keys, tokens, and secrets

Machines authenticate too, and they rarely use passwords. API keys, personal access tokens, cloud credentials, and secrets embedded in code or continuous-integration pipelines are all password-free entry points. A single access key committed to a repository or left in a build log can grant an attacker exactly what it granted the automation, no login prompt in sight. For an attacker, harvesting one of these is often easier, and quieter, than phishing a human.

#The side door: account recovery

Every login has a back door for people who forget their password: the recovery flow. If that flow is weaker than the front door, it becomes the target. Recovery tied to a phone number is exposed to SIM swap; recovery tied to an email account inherits that account's security; recovery relying on knowledge-based questions is undone by data already public or breached. Attackers routinely go around the password by resetting it, which requires the recovery path, not the secret.

#What actually raises the bar

Here is the same picture as a map: what each technique bypasses, and what stops it.

Notice how little of that column says "a stronger password." The recurring answers are phishing-resistant MFA, shorter-lived and bound sessions, conditional access that considers the device and context, governance over consent and secrets, and monitoring that notices a token being used from somewhere impossible. Passwords are the start of the story, not the end of it.