Should you really change all your passwords after a security breach?

Why does Google emphasize this password rotation?

A exploited vulnerability often opens more doors than one realizes. Attackers do not merely patch the bug for you: they collect credentials stored in plain text within databases, configuration files, or logs.

Even if you've patched the breach, exposed passwords remain valid. A patient attacker can wait weeks before reusing them. Immediate rotation invalidates these stolen keys and cuts off residual access.

Which accounts are affected by this rotation?

Google refers to all site access accounts, which encompasses much more than just your WordPress admin. FTP, SSH, MySQL databases, hosting panels, CDNs, third-party APIs: every compromised credential provides an alternative entry point.

Most practitioners neglect service accounts and API keys. A clever attacker specifically targets these secondary access points, which are less monitored than the super-admin account. Also consider former providers who still have active access.

Is this measure enough to secure the site after an attack?

Changing passwords is just a first defensive step, not a complete solution. If the attacker has installed a backdoor in the code, altered core files, or created hidden accounts, credential rotation alone will not suffice.

This action must be combined with a modified file audit, checking recently created users, and a malware scan. Sophisticated attacks leave several entry points: closing just one door does not secure the house.

• Rotate all credentials immediately after fixing the vulnerability
• Include FTP, SSH, databases, APIs, and third-party services in the rotation
• Combine with a thorough audit of files, users, and access logs
• Document who had access before the incident to detect residual accesses
• Monitor failed login attempts for at least 30 days post-incident

Is this recommendation consistent with observed practices on the ground?

Yes, but it often comes too late. Attacked sites discover the breach weeks after the initial intrusion when credentials have already been used to install multiple backdoors. Changing passwords at this stage limits future damage but does not rectify past issues.

What Google does not mention: most reinfections stem from credentials left behind in configuration files versioned on GitHub or in accessible backups. Rotation should be accompanied by cleaning up Git repositories and revoking publicly exposed API keys.

What nuances should be added to this guideline?

Password rotation becomes counterproductive if it leads teams to choose weak credentials because they have to remember them. Prefer a password manager and generate random passphrases of 20+ characters.

Another point: SSL/TLS certificates and private keys are not mentioned by Google but deserve attention. If the vulnerability provided access to the file system, these keys may have been exfiltrated. Rotating them involves regenerating CSRs and reissuing the certificates. [To be verified]: Google remains vague about the exact scope of "access accounts" involved.

In what cases does this rule not strictly apply?

If you use hardware two-factor authentication (FIDO2 keys) on all critical accesses, the risk of exploiting stolen credentials drops significantly. The attacker would also need the physical device along with the password.

Second exception: environments with centralized SSO authentication and automatic token rotation. In this case, revoking active sessions and forcing reauthentication may be sufficient if the tokens have a short lifespan. But be cautious: these architectures remain rare in the WordPress and classic CMS world.

What should you do concretely after fixing the vulnerability?

Start by listing all access points to the site: CMS admin, FTP/SFTP, SSH, databases, hosting panels, CDN access, API accounts (Google Search Console, Analytics, third-party SEO tools). A simple spreadsheet with columns "Service / Login / Last Modification" helps ensure nothing is missed.

Then, change the credentials in this order of priority: root and admin access first, then databases, and finally ancillary services. Between each rotation, verify that services restart correctly and that automated scripts (cron, deployments) function with the new keys.

What mistakes should be avoided when rotating passwords?

Do not document new credentials in a text file on the compromised server. Store them in a password manager like 1Password, Bitwarden, or Dashlane, never in a shared Google Doc or a local .txt file.

Another common mistake: forgetting to revoke old API keys. Changing the Google Search Console password is not enough if the old OAuth token remains active in a compromised third-party app. Revoke all OAuth accesses and regenerate the tokens.

How can you check if the site remains secure after the incident?

Set up active monitoring of connections for a minimum of 30 days. Plugins like Wordfence or Sucuri show failed login attempts and suspicious IPs. A spike in attempts on old logins confirms that stolen credentials are circulating.

Simultaneously, scan files modified recently with diff or WP-CLI to detect residual backdoors. A simple `wp core verify-checksums` reveals altered WordPress files. For custom themes and plugins, compare with your last clean version in Git.

• Inventory all system, CMS, database, and third-party API accesses
• Generate random passwords of 20+ characters via a dedicated manager
• Revoke all active OAuth tokens and API keys, even those that seem healthy
• Enable two-factor authentication on all critical accounts
• Monitor login logs and failed attempts for 30 days
• Scan modified files and verify the integrity of core files