Why storing WordPress admin passwords in your management dashboard is a bad idea

Most "manage multiple WordPress sites" tools work by having you enter the admin username and password for each site. The tool stores those credentials, encrypted, on its servers, and uses them to log in on your behalf whenever you trigger an update. This sounds reasonable. It isn't. Here's why the Manage GPL connector uses token-based authentication instead — and why you should prefer that model regardless of which vendor you use.

Three reasons password storage is risky

1. If the management vendor is breached, every site is breached

A single database dump would give an attacker admin access to every customer's every site. This isn't hypothetical: it has happened. Even with encryption at rest, the application has to decrypt credentials to use them, meaning keys sit in memory on servers that could be compromised.

2. Password reuse amplifies the blast radius

If a client reuses passwords (most do), that admin password is probably also their email password, their hosting panel password, and their bank password. A breach of the management tool becomes a breach of their whole digital life.

3. Passwords don't rotate automatically

When a staff member leaves, you have to remember every credential they had access to. With token-based auth, revoking one token on one site is a single click.

How token authentication works

The Manage GPL connection plugin generates a random token when you install it. That token, plus an HMAC signing secret, is registered with the Manage GPL dashboard via a one-time verification step. From then on:

• The dashboard sends signed requests to /wp-json/managegpl/v1/… endpoints.
• The connector verifies the HMAC signature and the nonce window (60 seconds) before executing anything.
• No admin username or password ever leaves the site.

If the dashboard is ever compromised, your WordPress admin account itself is still safe — the attacker would get only what the connector endpoints expose on your site (install/update plugins and themes, toggle maintenance mode, mint a one-time login URL if you're using the SSO feature). That's still serious, but it's a bounded blast radius that you can shut down from inside WordPress: open the connector plugin's settings and click Regenerate token. That action rotates the per-site HMAC secret, so any signed request the attacker had cached is immediately rejected. Per-site tokens mean revoking access is one click per affected site rather than rotating every WP admin password.

What to ask a management vendor

If you're evaluating tools, ask directly:

• Do you store my WordPress admin password, or do you use token-based authentication?
• If tokens: are requests signed with a per-site secret?
• Can I revoke access to a single site without losing access to all of them?
• If your dashboard is breached, what is the worst an attacker can do to my sites?

Any vendor that can't answer those cleanly isn't a vendor you should give twenty WordPress admin passwords to.