WordPress login: username vs. email, which is more secure?

WordPress login: username vs. email, which is more secure? The short answer is that neither a username nor an email address should be treated as the main security barrier protecting a WordPress account. Both are identifiers. The password, additional authentication factors and the wider login-security configuration are what should prevent unauthorized access.

There is, however, an important WordPress-specific detail: by default, WordPress can authenticate a user with either the account username or the account email address.

That means the same account can effectively be approached through two identifiers:

username + password

or

email address + password

If one identifier is public and the other is difficult to discover, allowing both can partly undermine the benefit of keeping the less visible identifier private.

This guide explains how WordPress handles username and email login, whether one option is inherently safer, how public usernames and email addresses affect account discovery, why identifier secrecy is only a limited security layer and when restricting WordPress to one login identifier can make sense.

Does WordPress allow login with both username and email?

Yes.

WordPress supports authentication using either a username or an email address in the standard login field.

The login form therefore commonly accepts:

Username or Email Address

WordPress implements these authentication paths separately through its core authentication callbacks.

The official wp_authenticate_username_password() documentation covers username authentication, while wp_authenticate_email_password() handles authentication using an email address.

The core wp_authenticate() documentation also notes that the login identifier can be an email address.

What is the difference between a username and an email address?

Both can identify a WordPress account, but they serve different purposes.

A WordPress username is the account’s login identifier and is stored separately from the user’s email address.

For example:

Username:
jane_admin

Email:
jane@example.com

By default, either value may be sufficient to identify the account during the normal WordPress login process.

The password must still be correct before authentication succeeds.

Is a username a secret?

No.

A username should not be treated like a password.

It may be exposed through normal WordPress behaviour, themes, plugins, APIs, author information or other public site features.

For example, a WordPress site may expose an author archive such as:

https://example.com/author/jane/

depending on how the site, theme and author slugs are configured.

Even when the public author slug does not exactly match the login username, the general security principle remains the same: account identifiers should not be treated as secret credentials.

Is an email address a secret?

Usually not in the same sense as a password.

Email addresses are routinely shared through:

• contact pages;
• business directories;
• author profiles;
• customer communications;
• support systems;
• company websites;
• data breaches;
• public records and social profiles.

An email address can therefore be extremely easy to discover for some accounts.

This is particularly relevant for business websites where addresses such as:

john@example.com
support@example.com
admin@example.com

may already be publicly visible.

So which is more secure: username or email?

Neither option is universally more secure.

The security difference depends primarily on how predictable or publicly discoverable each identifier is.

Consider two accounts.

Account A:

Username:
john

Email:
john@example.com

Both identifiers are easy to predict.

Account B:

Username:
w8k3m2q7

Email:
john@example.com

If WordPress accepts both identifiers, the difficult-to-guess username does not prevent somebody from simply attempting:

john@example.com

instead.

The attacker still needs the password, but there is no longer any practical need to discover the obscure username.

Username secrecy is only a minor defensive layer

Using a difficult-to-guess username can remove one obvious piece of information from an attacker.

That can be useful.

But it should not be confused with strong authentication.

If the password is:

password123

an obscure username does not transform the account into a secure one.

Likewise, if the account is vulnerable to credential stuffing because the same credentials were reused elsewhere, identifier obscurity provides limited protection.

OWASP’s Credential Stuffing Prevention Cheat Sheet describes credential stuffing as the reuse of stolen username-password or email-password combinations against other services.

What is username enumeration?

Username enumeration is the process of discovering valid account identifiers on a website.

An attacker may try to determine whether accounts such as:

admin
administrator
john
editor
support

exist.

Enumeration can happen through several channels depending on the WordPress installation and its plugins, themes and APIs.

Once a valid identifier is known, automated login attempts can focus on that account.

Does hiding a username stop brute-force attacks?

No.

It can make one part of account discovery less convenient, but it does not prevent an attacker from submitting authentication attempts.

A brute-force attack can involve trying many passwords against a known account.

Password spraying instead tries one or a small number of common passwords across many accounts.

Credential stuffing uses username-password or email-password combinations exposed elsewhere.

OWASP discusses these attack patterns in its Credential Stuffing Prevention Cheat Sheet.

Email addresses can also be enumerated

Switching from usernames to email addresses does not eliminate the concept of account enumeration.

An application can accidentally reveal whether an email address belongs to an existing account through differences in:

• login errors;
• registration responses;
• password-reset responses;
• API responses;
• response timing;
• custom account forms.

OWASP recommends avoiding responses that reveal whether a submitted account exists, particularly in authentication and password-recovery workflows.

See the OWASP Forgot Password Cheat Sheet for the account-enumeration considerations around recovery flows.

Using email login can improve usability

Email addresses have one significant usability advantage: users often remember them more easily than site-specific usernames.

This is particularly useful for:

• membership sites;
• WooCommerce stores;
• customer portals;
• large communities;
• websites where users create accounts infrequently.

A customer may forget that a website assigned:

johnsmith82

as a username three years ago.

They are considerably more likely to remember their email address.

Security architecture should account for usability because authentication systems that constantly force legitimate users into account recovery create their own operational problems.

Using username login can reduce reliance on public email addresses

For administrator or staff accounts, username-only authentication can be attractive when email addresses are already publicly known.

Suppose a company publishes:

jane@example.com

on its contact page.

If the same email address can authenticate directly to WordPress, an attacker already knows one valid identifier worth attempting.

If the site instead accepts only a separate, non-public username, discovering the public email address is no longer sufficient to identify the login value.

This does not replace password security or two-factor authentication, but it removes one authentication identifier that would otherwise be usable.

The important question is not only which identifier is harder to guess

A login identifier exists within a wider authentication system.

A more useful security review asks:

• Is the password strong and unique?
• Is two-factor authentication available?
• Are login attempts monitored or rate-limited?
• Can attackers easily discover valid account identifiers?
• Are privileged usernames publicly exposed?
• Are email addresses already public?
• Does account recovery reveal whether users exist?
• Are unused authentication paths still enabled?

The identifier is one layer in that system, not the entire security model.

Why WordPress accepts both username and email

WordPress separates the two authentication methods internally.

Conceptually, the authentication chain includes separate checks for:

username + password

email + password

The official authenticate filter documentation explains that WordPress uses the filter to perform authentication and additional validation during login.

Core attaches separate username and email authentication callbacks to this process.

This architecture is useful because plugins can modify authentication behaviour without replacing the complete login system.

What happens internally when you enter an email?

When email authentication is available, WordPress can resolve the submitted email address to a user account and then verify the password for that user.

The relevant core function is:

wp_authenticate_email_password()

Its official WordPress documentation describes it as the function that authenticates a user using an email address and password.

What happens when you enter a username?

Username authentication follows a parallel path through:

wp_authenticate_username_password()

The official WordPress documentation describes this function as validating a username and password combination.

This separation is important because it means a WordPress site can deliberately choose to stop accepting one identifier type without having to invent an entirely new authentication system.

Can WordPress be restricted to username-only login?

Yes.

Because username and email authentication are handled separately, WordPress authentication can be modified so that the login form accepts usernames but no longer authenticates email addresses.

Conceptually:

Username authentication
→ enabled

Email authentication
→ disabled

The user still needs the correct password.

The only change is which value WordPress accepts as the account identifier.

Can WordPress be restricted to email-only login?

Yes.

The reverse configuration is also possible:

Username authentication
→ disabled

Email authentication
→ enabled

This can make sense for customer-facing websites where usernames are primarily an internal WordPress implementation detail and email addresses are the identifier users already understand.

Is username-only login always safer?

No.

Username-only login is most useful when the username is less exposed or less predictable than the corresponding email address.

Consider:

Username:
admin

Email:
security-team@example.com

Restricting this account to the username:

admin

does not provide much identifier obscurity.

The value is extremely predictable.

Changing which identifier is accepted does not repair a poor identifier strategy.

Is email-only login always less secure?

No.

Email-only login can be perfectly reasonable when combined with strong authentication controls.

It can be especially appropriate for sites where:

• users already identify themselves by email;
• usernames are autogenerated;
• the account model is customer-facing;
• login usability is more important than keeping an identifier obscure;
• strong passwords and additional authentication controls are already in place.

The fact that an identifier is known does not mean the account is compromised.

A secure authentication system should assume that usernames and email addresses may eventually become known.

Known identifier does not mean known password

This distinction is important.

Knowing:

john@example.com

does not authenticate anyone.

The attacker still needs to satisfy the remaining authentication requirements.

Security problems arise when known identifiers are combined with weaknesses such as:

• weak passwords;
• password reuse;
• unlimited automated login attempts;
• missing two-factor authentication;
• weak recovery mechanisms;
• compromised credentials.

OWASP’s Authentication Cheat Sheet recommends treating authentication as a layered security problem rather than relying on identifier secrecy.

Why accepting both identifiers can increase the attack surface

If WordPress accepts both:

username
email address

then each account has two values that can identify it during the normal login flow.

For example:

Username:
7xq9km2

Email:
jane@example.com

An attacker does not need to discover 7xq9km2 if jane@example.com is already known and accepted by the same login form.

Restricting the site to one identifier removes the other value from that particular authentication path.

It does not make the remaining identifier secret or eliminate password attacks, but it narrows the set of identifiers that can successfully address the account.

Use one identifier when the distinction matters to your security model

For many WordPress sites, accepting both username and email is perfectly reasonable.

There is no requirement to disable one simply because WordPress supports both.

Restricting the login identifier becomes more relevant when the site deliberately relies on a distinction such as:

Public business email:
known

WordPress username:
not publicly exposed

Desired login:
username only

or:

WordPress username:
implementation detail

Customer email:
primary account identity

Desired login:
email only

The important part is making the choice deliberately rather than assuming WordPress already works one way or the other.

Restricting identifiers does not replace strong passwords

Suppose a site accepts only the username:

8qm4kd92

but the password is:

Welcome123!

The account still has a weak authentication design.

A difficult identifier may slow simple opportunistic guessing, but authentication security should continue to assume the identifier can eventually become known.

Restricting identifiers does not replace two-factor authentication

Two-factor authentication adds an additional authentication requirement after the primary credentials.

That provides a fundamentally different security property from obscuring or restricting an identifier.

An attacker who discovers the valid username and password may still be unable to complete authentication when an independent second factor is required.

OWASP describes multi-factor authentication as one of the strongest defenses against password-related attacks in its Multifactor Authentication Cheat Sheet.

For the WordPress implementation workflow, see How to set up an authenticator app for WordPress.

Restricting identifiers does not replace login hardening

A secure WordPress login strategy can involve several independent layers.

For example:

strong unique password
+
appropriate login identifier
+
two-factor authentication
+
controlled recovery
+
reduced unnecessary login exposure
+
monitoring and rate controls

No single layer needs to pretend it solves every authentication problem.

For the broader workflow, see A WordPress login hardening checklist.

Should administrators use a different username from their public name?

Usually, separating a public display identity from an account identifier can be sensible.

For example:

Public name:
Jane Smith

WordPress username:
js_7k4q2

is preferable to designing the system around the assumption that:

Public name:
Jane Smith

Username:
jane

Email:
jane@example.com

must all describe the account in the most predictable possible way.

The username should still not be treated as a secret comparable to a password, but there is little benefit in making privileged identifiers unnecessarily obvious.

Author archives can expose account-related information

WordPress sites may expose author archive URLs and other author metadata publicly.

If account identifiers are part of your defensive strategy, review what the site’s author system reveals rather than changing only the login form.

TheOneWP includes Hide Author Slug for sites that want public author URLs separated from the underlying WordPress username.

That is a different responsibility from restricting which identifier the login form accepts:

Hide Author Slug
→ changes public username exposure through author URLs

Restrict Login Identifier
→ controls whether username or email can authenticate

These controls can complement one another, but neither replaces password or multi-factor security.

Should you disable author archives entirely?

If author archives have no editorial or SEO purpose, removing them may be cleaner than maintaining public author URLs solely because WordPress creates them.

The decision should be based on the site’s content architecture, not only login security.

TheOneWP’s Disable Author Archive handles that separate use case.

If author archives are useful, keep them and configure their public identity appropriately instead of removing useful content merely to obscure a username.

Email addresses can also be exposed publicly

If a site deliberately chooses username-only authentication because email addresses are public, review where those email addresses are exposed.

Common locations include:

• author biographies;
• contact pages;
• team pages;
• mailto links;
• support documentation;
• structured contact information.

Preventing unnecessary scraping can be useful for spam reduction and identifier exposure, but public business email addresses should still be assumed discoverable eventually.

What about changing the WordPress login URL?

Changing:

/wp-login.php

to another route is a separate control from choosing which identifier is accepted.

One controls:

Where is the login form?

The other controls:

Which identifier can authenticate?

Neither should be confused with the password or second authentication factor.

TheOneWP’s Custom Login URL handles the endpoint side separately from identifier restrictions.

Do not rely on hiding wp-login.php alone

A custom login URL can reduce noise from automated requests targeting the standard WordPress endpoint, but it should remain one layer in a broader login-security model.

Account security should continue to assume that the authentication endpoint may eventually be discovered.

The same principle applies to usernames and email addresses.

Security based entirely on something remaining unknown is fragile.

What about XML-RPC and other authentication paths?

The normal WordPress login form is not necessarily the only authentication path associated with a WordPress installation.

Depending on the site’s configuration, plugins and integrations, authentication may also involve mechanisms such as:

• XML-RPC;
• Application Passwords;
• REST integrations;
• single sign-on;
• WooCommerce account flows;
• custom authentication endpoints.

Changing the identifier accepted by the standard interactive login form should therefore not automatically be assumed to redefine every authentication mechanism on the site.

Review each relevant authentication path separately.

Should you disable XML-RPC?

That depends on whether the site uses functionality that requires it.

If XML-RPC is unused, disabling that separate endpoint can reduce unnecessary authentication exposure.

If another system depends on it, disabling it can break legitimate functionality.

TheOneWP’s Disable XML-RPC addresses that separate surface.

Do not disable services merely because they are adjacent to login security. First establish whether the website actually uses them.

Which is better for a normal WordPress administrator?

If you are choosing specifically for a privileged administrator account, username-only login can be a reasonable additional layer when:

• the account username is not publicly exposed;
• the corresponding email address is public or easy to discover;
• the username is not something obvious such as admin;
• users can reliably store the identifier in a password manager;
• strong passwords and additional authentication controls are already used.

The value comes from removing a public email address as a valid login identifier, not from turning the username into a secret password.

Which is better for customers or members?

Email-only login can often provide a better user experience for customer-facing systems.

Users already understand their email address as an account identifier and do not need to remember another WordPress-specific value.

This can reduce:

• forgotten-username support requests;
• failed login attempts caused by forgotten usernames;
• confusion around autogenerated account names.

When the site already assumes that email addresses are known, there may be little security benefit in forcing users to remember an additional identifier purely for obscurity.

Which option should a membership site choose?

There is no universal answer.

A membership site with thousands of casual users may reasonably prioritize email login for usability.

An internal company WordPress installation with a small number of privileged accounts may prefer username-only login combined with non-public usernames.

The relevant decision is:

Who are the users?
↓
Which identifier is already public?
↓
Which identifier can users manage reliably?
↓
What other authentication controls exist?
↓
Does accepting both identifiers provide useful convenience?

Do not change identifier rules without warning users

If users currently log in with either value and the site suddenly restricts authentication to one identifier, some legitimate users may believe their credentials have stopped working.

Before changing an established site, consider:

• which identifier users normally enter;
• whether documentation needs updating;
• whether password-manager entries need changing;
• whether support staff understand the new rule;
• whether automated integrations use the same authentication path;
• whether administrators have tested the new configuration.

Test login changes with a second administrator session available

Authentication changes deserve controlled testing.

Before changing the accepted identifier:

1. Keep an existing Administrator session open.
2. Open a private browser window.
3. Test the identifier that should remain valid.
4. Confirm the expected login succeeds.
5. Test the identifier that should be rejected.
6. Confirm it no longer authenticates.
7. Test password recovery separately.
8. Verify any 2FA flow still works.

Keeping the original authenticated session open gives you a recovery path if the new login behaviour does not match expectations.

Do not confuse login identifier restrictions with password recovery

The password-reset system may still ask for or work with account information differently from the normal login form.

A site that accepts usernames only for authentication may still use the account email address for password recovery notifications.

That is normal.

Authentication and recovery are separate workflows and should be reviewed independently.

Should login error messages reveal which identifier is valid?

Ideally, authentication responses should avoid helping an attacker determine whether a particular account exists.

For example, a system should be cautious about exposing materially different messages such as:

This email exists, but the password is wrong.

versus:

No account uses this email address.

Differences like these can make account enumeration easier.

OWASP’s Authentication Cheat Sheet discusses generic authentication error responses as a defense against user enumeration.

Restrict Login Identifier in TheOneWP

If you want the standard WordPress login form to accept only one identifier type, TheOneWP’s Restrict Login Identifier provides a focused control for that purpose.

You can choose between:

Username only

or:

Email address only

The module works with WordPress’s native authentication architecture rather than building a separate login system on top of it.

In username-only mode, WordPress’s normal email authentication callback is removed from the standard authentication chain.

In email-only mode, the username authentication callback is removed instead.

The result is that the disallowed identifier is no longer considered by that login path.

Why removing one authentication callback is cleaner than validating the field afterward

A login restriction could theoretically be implemented by letting both authentication methods run and then trying to reject one afterward.

A cleaner design is to stop WordPress from attempting the disallowed identifier type in the first place.

The relevant core callbacks are:

wp_authenticate_username_password()

wp_authenticate_email_password()

TheOneWP’s Restrict Login Identifier works by disabling the appropriate native callback for the selected mode.

This keeps the restriction aligned with WordPress’s existing authentication pipeline.

Username-only example

Suppose an administrator account has:

Username:
wp_7k3f9

Email:
jane@example.com

and:

jane@example.com

is published on the company website.

With username-only login:

wp_7k3f9 + correct password
→ accepted login path

jane@example.com + same password
→ email identifier not accepted

The email address remains associated with the WordPress account for normal account purposes, but it is no longer accepted as the identifier by that login path.

Email-only example

Suppose a membership site creates usernames automatically:

Username:
user_583729

Email:
member@example.com

The member may have no reason to know or remember:

user_583729

Email-only login can provide a simpler experience:

member@example.com + correct password
→ accepted login path

user_583729 + same password
→ username identifier not accepted

What Restrict Login Identifier does not do

Restricting the accepted login identifier should not be mistaken for a complete login-security solution.

It does not replace:

• strong passwords;
• two-factor authentication;
• secure password recovery;
• rate limiting;
• monitoring;
• proper user permissions;
• security controls for other authentication paths.

Its responsibility is deliberately narrow:

WordPress accepts two identifier types by default

↓ restrict

WordPress accepts the selected identifier type

Does restricting login to one identifier halve brute-force risk?

Do not interpret the change as a precise mathematical reduction in account-compromise probability.

Removing one valid identifier narrows the values that can address the account through that login path, but actual attack risk depends on many variables, including:

• how easily the remaining identifier is discovered;
• password strength;
• credential reuse;
• automation protections;
• two-factor authentication;
• other authentication endpoints;
• attacker knowledge.

The benefit is best understood as reducing unnecessary identifier exposure rather than attaching an artificial percentage to the improvement.

What if both username and email are already public?

Restricting the site to one identifier can still reduce the number of accepted values, but it provides less obscurity when the remaining identifier is already known.

For example:

Username:
john

Email:
john@example.com

if both values are public, choosing one does not suddenly make account discovery difficult.

The account should instead rely primarily on strong authentication controls.

What if neither identifier is public?

If both are difficult to discover, accepting both still provides two valid identifiers rather than one.

Whether restricting that is worthwhile depends on the site’s threat model and usability requirements.

For a small set of privileged users, narrowing the login identifier can be reasonable.

For thousands of customer accounts, the usability benefit of email login may matter more than hiding an additional identifier.

What if users have multiple WordPress roles?

The login identifier belongs to the user account rather than to an individual role.

A user with:

Editor
+
Shop Manager

still has one account identity and one set of login identifiers.

Role configuration determines permissions after authentication.

It does not inherently determine whether username or email authentication succeeds.

Login identifier and authorization are different layers

This distinction is fundamental:

Identifier
→ which account are you claiming?

Password / second factor
→ can you authenticate as that account?

Roles and capabilities
→ what may the authenticated account do?

Changing username-versus-email login behaviour does not grant or remove WordPress capabilities.

Common username vs email login mistakes

1. Treating the username as a password

A username can be less visible than an email address, but it should never be the account’s primary security secret.

2. Using a random username while still allowing a public email address to log in

If the goal of the random username was to remove an obvious login identifier, accepting the public email address can defeat much of that specific benefit.

3. Assuming email-only login is automatically insecure

A known identifier is normal in authentication systems. The real protection should come from the rest of the credential stack.

4. Using predictable privileged usernames

Names such as:

admin
administrator
webmaster

provide little identifier obscurity.

5. Forgetting other authentication paths

Changing the interactive login form does not automatically redefine every API, integration or authentication mechanism installed on the site.

6. Restricting identifiers without telling users

An otherwise correct password can appear broken when the user submits an identifier that the site no longer accepts.

7. Ignoring account recovery

Login and password recovery are related but separate workflows.

8. Assuming identifier restrictions replace 2FA

They solve fundamentally different problems.

Username vs email security checklist

• Confirm whether the site currently accepts both username and email.
• Identify which account identifiers are publicly exposed.
• Avoid predictable privileged usernames where practical.
• Do not treat usernames as secret credentials.
• Assume public business email addresses can be discovered.
• Use strong unique passwords.
• Use two-factor authentication for privileged accounts where practical.
• Review login error messages for account-enumeration leaks.
• Review password-recovery behaviour separately.
• Check author URLs and other public account information.
• Review other active authentication paths.
• Decide deliberately whether accepting two identifiers is useful.
• Test identifier restrictions in a private browser window.
• Keep an authenticated recovery session available during changes.

Which login identifier should you choose?

For privileged WordPress accounts, username-only authentication can provide a useful additional layer when the username is intentionally non-obvious and the account email address is already public.

For customer-facing or membership sites, email-only authentication can offer better usability without inherently making the authentication system weak, provided the account is protected by appropriate password and additional security controls.

For many ordinary WordPress installations, accepting both identifiers may remain perfectly acceptable.

The key is understanding the tradeoff:

Both username and email
→ maximum login convenience
→ two accepted identifiers

Username only
→ potentially useful when email is public
→ users must know their username

Email only
→ simpler for customer-facing accounts
→ email is often easy to discover

Final thoughts: username vs. email, which is more secure?

WordPress username vs. email security is less about declaring one identifier universally superior and more about deciding how many account identifiers your login flow should accept.

WordPress normally supports both username and email authentication.

That is convenient, but it means every account can potentially be addressed through two different values.

If you deliberately maintain a non-public username for a privileged account while publishing its email address, continuing to accept that email at login reduces the value of keeping the username less visible.

If you run a customer or membership site, forcing users to remember obscure WordPress usernames may instead create unnecessary friction while providing little meaningful security benefit.

Choose the identifier that fits the site’s users and threat model, then protect the account with strong passwords, appropriate automation defenses, secure recovery and additional authentication factors where required.

If you want WordPress to accept only one identifier type, TheOneWP’s Restrict Login Identifier lets you choose username-only or email-only authentication while working with WordPress’s native authentication callbacks.

The identifier should make authentication deliberate.

The password and the rest of the security architecture should make unauthorized authentication difficult.