WordPress Password Security: Why Passkeys Are More Secure

Automated tools run credential attacks against WordPress login pages millions of times a day. They don’t choose targets manually, and they don’t need to know anything about your site beyond the URL. Your traffic volume, niche, and audience size make no difference. What matters is that your site runs WordPress and has a publicly accessible login page.

Wordfence has been protecting millions of websites from these attacks for years. Our threat intelligence team blocked over 16 billion brute force attacks against WordPress sites in Q1 2026 alone, from more than 68 million distinct attacking IP addresses. Strong passwords, two-factor authentication, login attempt limits, and leaked password protection all do real work against this.

But every one of those defenses protects a password, and the password itself is the problem. This article walks through how each of these attacks actually works, why hardening the login page cannot close all of them, and what changes when you replace the password with a passkey.

---

Automated Attack Methods Exploit WordPress Password Authentication

Automating credential attacks against WordPress is straightforward because the target is consistent. Every WordPress site exposes the same login endpoint, accepts the same credential format, and returns the same response signals.

---

Brute Force Scales With Automation

Brute force requires no prior knowledge of your site, only an accessible login endpoint. According to Microsoft, password attacks ran at 7,000 attempts per second in 2024, more than double the previous year’s rate.

On WordPress, these attacks target wp-login.php and the XML-RPC endpoint, both of which accept credential submissions on a default installation. Rate limiting raises the cost per attempt but doesn’t stop a distributed attack that routes through a different IP address on each submission, which is the standard evasion method for tools built specifically to work around basic login restrictions.

---

Credential Stuffing Runs on Purchased Breach Data

A malicious hacker running credential stuffing already has a confirmed username and password from a breach elsewhere and tests it against your login page because password reuse makes the attempt worth automating.

That’s not a rare occurrence either. According to the Verizon 2025 Data Breach Investigations Report, 88% of attacks against basic web applications involved stolen credentials, and credential stuffing accounted for 19% of all authentication attempts at the median organization.

Two-factor authentication (2FA) stops a stuffed credential from completing login even when it’s valid. Wordfence includes 2FA at no additional cost across all plans, including Free.

---

Phishing Proxies Capture TOTP Codes in Real Time

TOTP-based two-factor authentication adds a second factor to the login process, but because that factor is transmittable, it can be intercepted.

In January 2025, the Astaroth phishing kit appeared on criminal forums specifically as a TOTP bypass tool. It operates as a reverse proxy between the victim and the legitimate site, capturing the TOTP code the moment it’s submitted and forwarding it to the attacker before it expires. The victim completes 2FA and authenticates the attacker.

Evilginx works on the same principle at a larger scale. Instead of just relaying a TOTP code, it proxies the entire session and captures the authentication cookie issued after login, which works against SMS, TOTP, and push-based MFA alike.

Microsoft detected 8.3 billion email-based phishing threats in Q1 2026, which is the standard vector for this type of attack. And AI-driven personalization makes it even more threatening, with click-through rates up to 4.5 times higher (54% vs. 12%) than traditional phishing.

So, while 2FA helps protect against automated brute force and credential stuffing attacks, it can’t effectively protect against targeted phishing attacks that aim to capture TOTP codes.

---

External Breaches Become Your Problem Through Password Reuse

Credential stuffing at that scale works because most passwords protect more than one account. A credential confirmed in one breach is worth testing against every accessible login page, and your site is reachable from that list through nothing more than having a login form.

---

Billions of Pre-Validated Credentials Are Available To Buy

Malicious hackers don’t build credential lists from scratch. They buy or download them from criminal markets where stolen login data from thousands of breaches accumulates year over year.

In fact, Verizon found that 2.8 billion passwords appeared on criminal forums in 2024 alone. These are confirmed credentials from real accounts, which is what makes testing them against new login forms worth automating at scale.

Running a credential stuffing campaign requires nothing more than a purchased list, an automated tool, and a rotating pool of IP addresses to work around rate limiting.

---

Password Reuse Turns Any External Breach Into a Credential Supply

That market works because most passwords protect more than one account. SpyCloud found that 70% of users exposed in data breaches in 2024 had reused the exposed password on other accounts.

Similarly, Verizon reported that the median user has only 49% distinct passwords across all their services, meaning roughly half the passwords in active use today match a password used somewhere else.

A malicious hacker who acquires a list from a different breach doesn’t need to target your site directly. Those credentials arrive pre-validated, sourced from someone else’s compromise, and ready to test against your login form.

---

Password Managers Don’t Fix the Authentication Model

A password manager is the most practical response to reuse. These tools generate unique, random passwords for every site, cutting off the supply chain that makes credential stuffing viable. With every password distinct, a breach of one service produces credentials that don’t work anywhere else.

However, the authentication model underneath those passwords doesn’t change. A randomly generated password still crosses the network on every login, still gets stored server-side as a hashed value that attackers can target after a breach, and still presents something interceptable to a real-time phishing proxy.

---

Weaknesses WordPress Password Security Can’t Fix

Stronger passwords, unique credentials across sites, and TOTP-based 2FA address specific attack patterns and are worth having. What they don’t do is change the underlying authentication model.

Password authentication is a shared secret system. Both you and the server hold a copy, and each copy carries its own exposure. Best practices protect the credential from being guessed, but it leaves two copies of it in place.

---

Every Credential Database Is Worth Breaching

For password authentication to work, the server needs to store something it can compare against what you submit at login. Typically, that’s a hashed version of your password, a scrambled representation that the server checks without storing the original. That database has to exist, and because it does, it’s a target.

A breach that produces your credential database gives an attacker a starting point for cracking. The outcome depends on the hashing algorithm and available hardware, but for most credentials that have been reused elsewhere, the window between breach and usable plaintext is shorter than most site owners expect.

---

Hashing Only Delays Credential Exposure

Hashing is designed to make a password hard to reverse, not impossible. When a credential database is stolen, the attacker has a list of scrambled values and the computational task of finding the inputs that produced them.

Modern GPUs run that calculation fast enough to crack common passwords within hours. SpyCloud verified this directly, with researchers cracking 93% of hashed passwords recovered from breaches into plaintext.

Bcrypt resists GPU-based cracking more effectively than MD5 and adds meaningful cost to the process, but that cost buys time rather than permanent protection.

---

Password Resets Create a Second Path Into Your Site

A password reset flow sends a link to the email address on file, which works only as long as that account is secure. If it’s been phished, its password reused from another breach, or the device receiving mail is already compromised, the reset flow becomes a second path into your WordPress site that bypasses the authentication controls configured at the application layer.

Sites that enforce strong passwords and 2FA on WordPress logins often retain this recovery path by default. A malicious hacker who can’t get through your WordPress login can target the associated email account and use the password reset to walk in anyway.

---

Passkeys Close the Attack Surfaces That Passwords Cannot

Every attack surface depends on a shared secret existing somewhere accessible. Passkeys close these surfaces by removing the shared secret that attackers are targeting, rather than hardening it.

The private key that authenticates a passkey is never sent to the website, never crosses the network, and is never stored on your server.

---

Passkeys Leave Nothing on the Server Worth Stealing

When you register a passkey, the authenticator generates a key pair. The public key goes to the server, while the private key remains protected by the user’s authenticator or passkey provider and is unlocked through biometrics or a PIN.

During login, the server issues a cryptographic challenge, the device signs it with the private key, and the server verifies the signature against the stored public key.

The server holds only the public key, which is designed to be shareable and provides no authentication capability on its own. A breach of a passkey database produces a list of values that an attacker cannot use to log in anywhere.

---

Domain Binding Defeats Phishing Proxies

When you register a passkey with a service, it’s bound to that service’s exact domain at the protocol level. During authentication, your device checks that the domain in the incoming request matches the domain the passkey was registered for, and if it doesn’t, the authenticator produces no response.

That domain check is what closes the attack vector that Astaroth-style proxies exploit. TOTP codes have no binding to the site they were meant for and work wherever they’re submitted, which is what makes real-time proxies effective against them.

On the other hand, a passkey authenticator checks the origin before signing, so when a phishing site presents a different domain, there’s nothing for the proxy to relay.

A FIDO Alliance case study revealed Google recorded zero successful phishing attacks against its workforce of more than 85,000 employees after requiring FIDO security keys for all work account sign-ins.

---

The Usability Case for Passkeys Is As Strong as the Security Case

Most security controls trade usability for coverage. Passkeys are an exception, outperforming passwords on sign-in reliability and speed, alongside the security advantages.

Microsoft’s 2025 passkeys research showed that passkeys achieve a 98% sign-in success rate against 32% for passwords. The FIDO Alliance Passkey Index 2025 documents a similar gap, with passkeys succeeding 93% of the time against 63% for traditional authentication methods.

Lower failure rates translate to fewer locked-out users, fewer password reset requests, and faster logins. Microsoft found passkey sign-in to be eight times faster than a password combined with multi-factor authentication, making passkeys one of the few security controls that also reduce friction for the user.

---

Wordfence Brings Passkey Authentication to Every WordPress Site

Passkey authentication isn’t included in WordPress core as of version 7.0.1, so it requires a plugin. Wordfence adds it through the same plugin already managing your site’s firewall, malware scanning, and two-factor authentication.

---

Enabling Passkeys Through Wordfence Login Security

Passkeys are enabled through Wordfence’s login security settings, the same location where two-factor authentication lives.

You enable the feature, and your users register passkeys through their individual WordPress profiles. At login, the passkey replaces the password, and authentication happens through the device’s biometric or PIN rather than anything typed.

Platform support covers all major authenticators:

• Apple (iOS 16 / macOS Ventura and later): iCloud Keychain handles passkey storage and syncs credentials automatically across Apple devices.
• Android (version 9 and later): Google Password Manager stores and syncs passkeys across Android devices.
• Windows (version 10 and later): Windows Hello handles passkey authentication using biometrics or a PIN.
• FIDO2 hardware security keys: YubiKey and similar hardware keys work for users who want a credential that operates independently of any platform or sync service.
• Third-party password managers: Bitwarden, 1Password, and other FIDO2-compliant managers are supported for users who already manage credentials across devices through these tools.

---

Enforce Passkeys by Role Without a Full Cutover

Role-level passkey enforcement works the same way our 2FA enforcement does. You can make passkeys available to all users immediately or phase in the requirement by role while you plan the broader rollout.

The practical starting point is to enable passkeys for all users, then enforce the requirement for administrator and editor roles first. Subscriber-level accounts can follow on a separate timeline. That approach locks down your highest-privilege access without requiring less technical users to complete the transition at the same time.

---

Passkeys and Passwords Can Coexist During Rollout

Passkeys and password authentication can coexist during a transition period. Users who’ve registered a passkey authenticate with it, while those who haven’t can still use their password. Enforcement can be introduced gradually by role, the same way you handle phased 2FA rollout.

Retaining password login as a fallback keeps the phishing surface partially open for accounts that haven’t yet enrolled. A fully hardened site disables username and password login for roles where passkeys are enforced.

If a user loses access to their passkey device, any site administrator can remove the existing passkey through Wordfence’s settings and reset the grace period to allow login through an alternate method. WP-CLI commands are available for site owners who need to perform the same actions remotely.

---

Strengthen Your WordPress Site Security With Passkeys

The credential attack surface on WordPress is wider than the login page. Password best practices cover the attacks that target wp-login.php directly. They don’t cover server-side databases that become targets the moment they hold hashed credentials, recovery paths that reintroduce phishing exposure, or credential markets sustained by the reuse that makes every external breach a potential risk to your site.

All of those attack patterns depend on a shared secret existing somewhere accessible, and passkeys remove that dependency entirely.

Wordfence Free gives any WordPress site access to passkey authentication, the endpoint firewall, a malware scanner, and two-factor authentication at no cost, with firewall rules and malware signatures updating on a 30-day delay. Wordfence Premium adds real-time firewall rules, malware signatures, and the IP blocklist for sites that need tighter coverage.

For sites where a credential compromise or breach carries real operational consequences, Wordfence Care handles installation, configuration, optimization, and ongoing security management with unlimited incident response during business hours. Wordfence Response extends that to 24/7/365 coverage, a one-hour response time, and a 24-hour resolution guarantee.