Secure Your WordPress Credentials — Admin, FTP, Database

A single WordPress site generates a surprising number of credentials. The admin panel login, the FTP or SFTP account for file transfers, the MySQL database credentials in wp-config.php, the hosting control panel and the domain registrar account. For a web agency managing 20 or 30 client sites, that quickly adds up to hundreds of credential sets — each one a potential entry point for an attacker.

Despite this, most agencies and freelancers still manage WordPress credentials in ways that would make any security auditor wince: shared Google Sheets, email threads with passwords in the subject line or sticky notes on a monitor. The problem is not a lack of awareness — it is a lack of practical workflow that fits how WordPress professionals actually work.

The Credential Sprawl Problem

A typical WordPress project involves at least five distinct sets of credentials:

Each credential has a different rotation cycle, different people who need access and different consequences if compromised. The WP admin password might change monthly, while the database credentials have not been touched since the site was launched three years ago.

Common Anti-Patterns in WordPress Agencies

The Shared Spreadsheet

The most widespread pattern is a Google Sheet or Excel file titled something like "Client Credentials" shared across the team. On the surface it seems organized — one row per site, columns for each credential type. In practice, it is a disaster:

• Anyone with the link has access to every client's credentials
• There is no access log — you cannot tell who viewed which password
• When a team member leaves, you need to change every password in the sheet (and nobody does)
• The sheet is often shared with the client too, meaning it is accessible from devices you do not control

The Email Chain

Hosting providers send initial credentials by email. Developers forward those emails to colleagues. The password lives in five inboxes, searchable forever, backed up to personal devices and potentially accessible through compromised email accounts.

The wp-config.php Screenshot

Need the database credentials? SSH into the server, cat wp-config.php and screenshot the output. Send it via Slack. Now the database password exists as an image file in Slack's CDN, your screenshot folder and possibly your cloud photo backup.

Organizing Credentials with Folders and Templates

The first step toward sanity is organizing credentials in a vault with a clear folder structure. Create one folder per client, then store all related credentials inside it:

Acme Corp/
  ├── acme.com - WP Admin          (vault entry: site, username, password)
  ├── acme.com - SFTP              (Secure Item: SSH Server template)
  ├── acme.com - Database          (Secure Item: Database template)
  ├── acme.com - OVH Hosting       (vault entry: site, username, password)
  └── acme.com - Gandi DNS         (vault entry: site, username, password)

Baker Design/
  ├── bakerdesign.fr - WP Admin
  ├── bakerdesign.fr - FTP
  ├── bakerdesign.fr - Database
  └── bakerdesign.fr - Ionos Panel

For structured credentials like SSH servers and databases, use dedicated item templates instead of plain vault entries. These templates have fields designed for the specific credential type:

SSH Server Template Fields

Label:      acme.com Production SFTP
Host:       sftp.acme-hosting.com
Port:       22
Username:   acme_deploy
Auth:       Key-based (private key in Notes field)

Database Template Fields

Label:      acme.com MySQL Production
Host:       localhost
Port:       3306
Database:   acme_wp
Username:   acme_dbuser
Password:   (generated, 32 chars)
Notes:      Read replica at db-replica.internal:3306

Team Access with Granular Permissions

Not everyone on the team needs access to every credential. A content editor needs the WP admin login but should never see the database password. A junior developer might need SFTP access but not the hosting panel.

With team-based sharing, you can control this precisely:

• Content team — Read-only access to WP admin entries only
• Development team — Read-write access to WP admin, SFTP and database entries
• Infrastructure team — Full access including hosting panels and domain registrars

When a freelancer finishes their contract, remove them from the team. Their access to every shared credential is revoked instantly — no need to rotate passwords across 30 client sites. Of course, if the freelancer had time to copy credentials during their engagement, rotation is still advisable for high-value accounts.

Auto-Fill for WordPress Login Pages

One of the practical benefits of storing WP admin credentials in a vault is auto-fill. Instead of looking up the password, copying it and pasting it into the wp-login.php page, the browser extension fills it automatically. This sounds minor, but for an agency logging into dozens of client sites daily, it eliminates a significant source of friction — and removes the temptation to use the same password everywhere.

The extension detects the WordPress login form, matches the current domain against your vault entries and fills the username and password fields. If auto-login is enabled, it submits the form automatically after filling.

For sites with custom login URLs (a common WordPress security hardening practice using plugins like WPS Hide Login), add the custom URL to the entry. The extension matches on the full URL, not just the domain.

The wp-config.php Problem

WordPress stores database credentials in plaintext in wp-config.php. This is a framework requirement that cannot be changed. However, you can mitigate the risk:

// wp-config.php — credentials still in plaintext (WordPress requirement)
// But at least they are unique, strong and tracked in your vault

define('DB_NAME',     'acme_wp_prod');
define('DB_USER',     'acme_dbuser');
define('DB_PASSWORD', 'xK9#mP2$vL7nQ4wR8jF5bH3cY6tA0eD');
define('DB_HOST',     'localhost');

The password above was generated by a password manager — 32 characters, mixed case, numbers and symbols. It is stored in the vault's Database template entry for this client. When the password is rotated, the developer updates both the vault entry and the wp-config.php file, and password history tracks every previous value.

Handling Client Handoffs

When a client moves to a different agency or takes their site in-house, you need to transfer all credentials cleanly. Instead of composing an email with five passwords in plaintext, use an encrypted link with a short TTL:

• Export the relevant credentials as a SecureSend (encrypted, single-use, 24-hour expiry)
• Send the link to the client's designated contact
• Once they confirm receipt, revoke all team access and rotate any credentials that were shared

The client receives the credentials through a zero-knowledge encrypted channel. Nothing appears in email bodies or chat messages. After 24 hours, the link self-destructs.

A Practical Migration Plan

If your agency currently uses spreadsheets or email for credential management, here is a realistic migration path:

• Week 1 — Set up your vault with a folder per client. Import existing credentials from your spreadsheet (CSV import handles most formats automatically).
• Week 2 — Create teams for each department (content, development, infrastructure). Share appropriate entries to each team with the right permission level.
• Week 3 — Install the browser extension for the team. Enable auto-fill for WP admin sites. Let the team adapt to the new workflow.
• Week 4 — Delete the old spreadsheet. Rotate the most critical credentials (hosting panels and database passwords) to ensure the old values from the spreadsheet are no longer valid.

The entire migration takes a month of part-time effort. After that, every credential is encrypted, access-controlled and auditable. UnveilPass supports CSV import from Chrome, Firefox, Bitwarden, LastPass and five other sources, so the initial data migration is typically the fastest part.