Authentication guide
WordPress application passwords, explained.
A 24-character code you generate for one app to use, not the password you type at the login screen. Confusing the two is where most of the risk lives.
Generated on demand, named for what uses it, and revocable individually without touching your login password.
WordPress stores it with a fast hash, not bcrypt — deliberately, because of what it's protecting against.
Including anything gated only at that form, like a 2FA prompt. Treat it as a full credential.
What an application password actually is
Since WordPress 5.6, every user account can generate application passwords from their profile screen: a 24-character code shown once, in the familiar xxxx xxxx xxxx xxxx xxxx xxxx grouping, tied to a name you choose ("Jetpack", "iOS app", "deploy script"). It exists specifically to authenticate against the REST API and XML-RPC using HTTP Basic Auth — the username stays the same, but the password field takes the generated code instead of your real one.
The name isn't cosmetic. It's the only record of what a given credential is for, which matters the day you need to revoke exactly one of them without guessing which is safe to kill.
Why WordPress doesn't bcrypt it
bcrypt earns its cost deliberately — it exists to make guessing a short, human-chosen password expensive. An application password isn't human-chosen: it's 24 characters of WordPress's own random generation, comfortably outside brute-force range regardless of hash speed. Spending bcrypt's extra milliseconds on every REST API request to defend a secret that was never guessable in the first place is pure overhead with no real security benefit.
That's why WordPress 6.8's move to bcrypt for login passwords deliberately left application passwords on a fast hash — see the 6.8 hashing change guide for the other cases that got the same treatment (password-reset keys, personal-data-request keys). Different threat, different tool.
Where they're created, and what revoking one does
Users → Profile → Application Passwords, for any account with the capability (administrators can typically manage this for others too, depending on the site's configuration). Revoking a specific one immediately stops authentication for whatever used it — nothing else on the account changes, and your regular login password is completely unaffected either direction.
A site can also disable the feature entirely via a filter, or it may already be unavailable if the site isn't served over HTTPS — WordPress requires a secure connection (or an explicit opt-in for local development) before allowing application passwords at all.
Treat them as real credentials
- Name each one specifically enough that "what is this for?" has an obvious answer six months later.
- Revoke anything you don't recognize or no longer use — an unused application password is a live credential nobody is watching.
- Remember it skips your login form's protections: if you rely on 2FA there, it does not extend to REST API requests authenticated this way.
- Never reuse one across unrelated integrations. Generate a new one per app, exactly as the feature intends.
Quick answers
Does two-factor authentication protect application passwords?
No. 2FA gates the login form; application passwords authenticate directly against the REST API or XML-RPC and never pass through that form. This is exactly why an unused, forgotten one is a real risk rather than a theoretical one.
Can I just use my real password for REST API access instead?
No — application passwords are the supported mechanism for Basic Auth against the REST API. Using your account password there isn't the intended flow and most setups won't accept it that way.
Are application passwords stored as $wp$2y$ hashes?
No. WordPress hashes them with a fast algorithm rather than bcrypt, because their high entropy makes bcrypt's slow-by-design cost unnecessary — see the 6.8 hashing change guide for why that trade-off makes sense here specifically.
What happens to existing integrations if application passwords are disabled?
Anything authenticating with one stops working immediately — the credential is no longer accepted. Confirm what depends on the feature (Jetpack, mobile apps, CLI tools, custom integrations) before turning it off site-wide.
Primary reference: WordPress REST API: Authentication.