How to manage website passwords securely?

You manage website passwords securely by keeping every credential in a reputable password manager, making each one long, random, and unique, protecting the important accounts with two-factor authentication or passkeys, and sharing access through individual accounts or shared vaults instead of emailing passwords around. Just as important is knowing which credentials your website depends on, so you can rotate them when someone leaves or something goes wrong.

A typical website involves far more passwords than most owners realise: the domain registrar, DNS provider, hosting account, control panel, SFTP or SSH, database, CMS admin, email, payment gateway, analytics, and a handful of API keys. Any one of these can be the weak link. This article shows you how to build a credential inventory, choose and organise a password manager, create strong credentials, share access safely, handle secrets in code and configuration, and rotate passwords without breaking anything.

Why Website Passwords Need Special Care

Personal passwords protect one person's accounts. Website passwords often protect a business, its customers' data, and its revenue, and they're frequently shared between several people. That combination creates problems:

• Sprawl: Credentials end up in emails, chat messages, spreadsheets, sticky notes, and the heads of former contractors.
• Reuse: The same password gets used for hosting, WordPress, and email because it's "easier", so one leak unlocks everything.
• Orphaned access: Freelancers finish a project but their logins keep working for years.
• Hidden dependencies: Nobody remembers which API key the contact form uses until it stops working.

Attackers rely on exactly these weaknesses. Credential stuffing, where leaked username and password pairs from one breach are tried on other sites, works because people reuse passwords. A strong, organised approach removes that opportunity.

Step 1: Build a Credential Inventory

Before improving anything, list every account that has power over your website. Group them by how much damage they could do if stolen.

Critical (Can Take Over Everything)

• Domain registrar: Whoever controls this can point your domain anywhere.
• DNS provider: If separate from your registrar, such as Cloudflare.
• Hosting account and control panel: cPanel, Plesk, or your cloud provider's console.
• Primary email account: Used for password resets on everything else.

High (Can Alter or Steal Site Data)

• CMS administrator accounts: WordPress, Shopify, or similar.
• SSH, SFTP, and deployment keys.
• Database credentials.
• Payment gateway dashboards: Stripe, PayPal, and so on.

Medium (Can Cause Disruption or Leaks)

• Third-party API keys: Email services, maps, search, AI tools.
• Analytics, tag manager, and marketing tools.
• Backup storage: Often overlooked, but backups contain your entire site and database.

For each entry, note who has access, whether two-factor authentication is on, and where the credential is stored. This list becomes the foundation of your password vault.

Step 2: Use a Password Manager

A password manager is the single most effective tool for managing website credentials. It generates strong passwords, stores them encrypted, fills them in for you, and lets you share access with other people in a controlled way.

Well-established options include:

• 1Password: Popular with teams, with strong sharing features and a polished interface.
• Bitwarden: Open source, affordable, and can be self-hosted.
• Proton Pass: From the company behind Proton Mail, with a privacy focus.
• Keeper and Dashlane: Business-focused options with admin controls.
• KeePassXC: A free, offline, open-source option if you prefer to keep a local encrypted file.

For a business or agency, choose a plan with shared vaults, per-user accounts, and an admin console so you can revoke access when someone leaves. Whatever you pick, protect the password manager itself with a long, memorable master passphrase and two-factor authentication, ideally a hardware security key or passkey.

Organise Your Vault

Structure makes a vault useful rather than just a pile of logins:

1. Create a vault per website or client: For example, "Example.com – Production".
2. Use consistent item names: "Example.com – Hosting (cPanel)", "Example.com – WordPress Admin", "Example.com – Database".
3. Store context in notes: The login URL, the account owner, which services use this credential, and when it was last rotated.
4. Keep recovery codes with the account: Two-factor backup codes belong in the same item, or in a separate high-security vault.
5. Separate personal and business items: Staff shouldn't store business credentials in personal vaults.

Step 3: Create Strong, Unique Credentials

A strong password in 2026 is long and random rather than clever. Let your password manager generate them:

• Random passwords: At least 16 characters, ideally 20 or more, using letters, numbers, and symbols. Use these for anything the password manager will fill in.
• Passphrases: Four to six random words, like lantern-orbit-velvet-cactus-mild, for the few things you must type from memory, such as your password manager master password or computer login.

Never reuse a password across accounts. If your hosting password leaks in some unrelated breach, it shouldn't also unlock your registrar.

You can generate a strong random secret from the command line when you need one for configuration, such as a database password:

# 32 random bytes, base64 encoded
openssl rand -base64 32

# A URL-safe alternative using Python
python3 -c "import secrets; print(secrets.token_urlsafe(32))"

Turn On Two-Factor Authentication Everywhere It Matters

Passwords alone are no longer enough for critical accounts. Enable two-factor authentication on your registrar, DNS, hosting, email, CMS admin accounts, and payment dashboards. Prefer, in order: passkeys or hardware security keys, then authenticator apps, and only use SMS if nothing else is offered. For WordPress specifically, we have a separate guide on setting up two-factor authentication.

Step 4: Share Access Without Sharing Passwords

The best password to share is one you don't have to share at all.

Give Each Person Their Own Account

Most services let you add users with their own logins. Do this wherever possible:

• WordPress: Create a separate user for each person under Users > Add New User, with the lowest role that lets them do their job.
• Hosting: Many hosts and cloud providers support team members or sub-users with limited permissions.
• Registrars and DNS: Cloudflare, for example, supports multiple members with scoped roles.
• SFTP and SSH: Create individual accounts or add each person's own SSH public key.

Individual accounts mean you can see who did what and remove one person without changing everyone else's access.

When You Must Share a Credential

Some accounts only allow one login. In those cases:

1. Share through the password manager: Put the item in a shared vault or use the manager's secure sharing feature, which lets you revoke access later.
2. Use time-limited links for outsiders: Features like 1Password's item sharing or Bitwarden Send create expiring, encrypted links.
3. Never send passwords in email, SMS, or chat: Those messages live forever in multiple places and are often searchable.
4. Rotate after the job: When a contractor who had a shared password finishes, change it.

Step 5: Handle Secrets in Code and Configuration

Websites also rely on machine credentials: database passwords, API keys, SMTP credentials, and salts. These need as much care as human passwords.

Keep Secrets Out of Version Control

Never commit secrets to Git, even in a private repository. Repositories get cloned, shared, and occasionally made public by mistake, and removing a secret from Git history is painful. Use environment variables or configuration files that are excluded from the repository:

# .gitignore
.env
.env.*
wp-config.php
!.env.example

Commit an .env.example with placeholder values so developers know which variables are needed, without exposing real ones.

Load Secrets From the Environment in WordPress

You can keep secrets out of wp-config.php itself by reading them from environment variables set by your host or server. Place code like this in wp-config.php, above the "That's all, stop editing!" line:

<?php
// Read database credentials from environment variables when available.
define( 'DB_NAME', getenv( 'WP_DB_NAME' ) ?: 'wordpress' );
define( 'DB_USER', getenv( 'WP_DB_USER' ) ?: 'wordpress' );
define( 'DB_PASSWORD', getenv( 'WP_DB_PASSWORD' ) ?: '' );
define( 'DB_HOST', getenv( 'WP_DB_HOST' ) ?: 'localhost' );

// Third-party API key used by a custom plugin.
define( 'SAJJAD_MAILER_API_KEY', getenv( 'SAJJAD_MAILER_API_KEY' ) ?: '' );

Then, in your plugin, read the constant rather than hard-coding the key:

<?php
function sajjad_get_mailer_api_key() {
    if ( defined( 'SAJJAD_MAILER_API_KEY' ) && SAJJAD_MAILER_API_KEY ) {
        return SAJJAD_MAILER_API_KEY;
    }
    return '';
}

Also make sure wp-config.php has tight file permissions, such as 600 or 640 depending on how your server runs PHP, so other users on the server can't read it.

Use Scoped API Keys

When a service lets you choose permissions for an API key, give it only what it needs. A contact form doesn't need an email service key that can delete your whole account; it needs one that can send mail. Stripe restricted keys, Cloudflare API tokens, and AWS IAM policies all support this.

For Larger Teams: Secrets Managers

If you run multiple environments or deploy through CI/CD, consider a dedicated secrets manager such as AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler, or 1Password's developer tools. Your deployment platform, whether GitHub Actions, GitLab CI, or Vercel, also has encrypted secret storage for build and runtime variables.

Step 6: Rotate Passwords at the Right Times

Current guidance, including NIST's digital identity guidelines, advises against forcing regular password changes for no reason, because it leads people to pick weaker, predictable passwords. Instead, rotate credentials when there's a trigger:

• Someone with access leaves: Staff, freelancers, or agencies.
• A credential may have been exposed: It was sent in chat, pasted in a ticket, or appears in a breach notification.
• A service reports a breach.
• After a security incident on your site: Assume every credential on the server is compromised.
• Old credentials you can't account for: If you don't know who has a password, change it.

How to Rotate WordPress Credentials

To reset a WordPress user's password with WP-CLI and log them out everywhere:

# Generate a new strong password for a user and show it once
wp user reset-password editor-jane --show-password

# Destroy all active login sessions for that user
wp user session destroy editor-jane --all

To invalidate every logged-in session on the site at once, replace the authentication keys and salts in wp-config.php with fresh values from https://api.wordpress.org/secret-key/1.1/salt/. With WP-CLI:

wp config shuffle-salts

Rotating Database Passwords Safely

Changing a database password requires updating both the database user and the application's configuration, in the right order, to avoid downtime:

ALTER USER 'wp_user'@'localhost' IDENTIFIED BY 'new-long-random-password';
FLUSH PRIVILEGES;

Then immediately update DB_PASSWORD in wp-config.php or your environment variables. Take a backup before you start, and do it during a quiet period.

Step 7: Plan for Recovery and Offboarding

Good password management includes what happens when things go wrong.

1. Protect recovery paths: Your registrar and hosting accounts should use an email address on a domain other than the one being protected, or at least one with strong two-factor authentication. If your domain expires or DNS breaks, you don't want password reset emails going to a mailbox that no longer works.
2. Store emergency access securely: Business password managers offer emergency access or account recovery for admins. Set it up so the business isn't locked out if one person is unavailable.
3. Keep an offboarding checklist: When someone leaves, remove their accounts, revoke their SSH keys and API tokens, remove them from shared vaults, and rotate any shared credentials they knew.
4. Review regularly: Every few months, go through your inventory and remove access that's no longer needed.

Common Password Mistakes to Avoid

• Saving passwords in the browser on shared computers: Use a password manager with its own lock instead.
• Using the site's domain name in the password: Attackers try variations of the domain first.
• Keeping default credentials: Change any default username and password on routers, control panels, or database tools like phpMyAdmin.
• Putting credentials in screenshots or documentation: Reference the password manager item instead.
• Letting one person hold every key: If they leave or become unavailable, the business is stuck.

---

FAQ: Managing Website Passwords Securely

---

Conclusion

Managing website passwords securely comes down to a few habits applied consistently: know what credentials you have, store them in a password manager, make each one strong and unique, add two-factor authentication to the accounts that matter, and give people their own logins instead of passing shared ones around. For machine credentials, keep secrets out of your code and give API keys only the permissions they need.

None of this requires deep technical knowledge, but it does require a little organisation up front. Spend an afternoon building your inventory and moving everything into a vault, then set a reminder to review it every few months. That small investment closes off some of the most common ways websites get compromised.