# Admin passwords and shared access > A password reused across three services, FTP access given to a provider and never revoked, an admin account created "just to help out" and forgotten: these are human flaws, not technical ones, and they’re among the easiest to fix. - Source canonique : [https://allaux.fr/en/securite/mots-de-passe-administration-acces-partages](https://allaux.fr/en/securite/mots-de-passe-administration-acces-partages) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > Start with an inventory of access rather than a password change: privileged accounts in wp_users on WordPress or ps_employee on PrestaShop, then the FTP and SSH accounts in the hosting panel. Delete the ones that no longer match anybody. On WordPress, replacing the salt keys in wp-config.php logs out every open session at once. ## A different category of flaw SQL injections or outdated modules are flaws in the code. The ones on this page aren’t: they come from how access is created, shared, and never withdrawn. A password reused across your inbox, your host and your CMS back office means a data leak on a completely unrelated service can hand someone access to your store. FTP credentials sent by email to a provider, never revoked after the job ends, stay valid indefinitely as long as nobody remembers to change them. This type of flaw never shows up in a vulnerability report and never carries a CVE identifier. Yet it’s one of the most direct entry points, because it doesn’t require any technical flaw at all: the attacker simply logs in, with valid credentials. ## Automated attempts are constant > Brute-force attacks against login pages, wp-login.php on WordPress or the admin page on PrestaShop, are a continuous and well-documented phenomenon across the web. They aren’t targeting your store specifically: bots constantly test common combinations against thousands of sites indiscriminately, hoping a weak password gives way. ## A detail few merchants know about PrestaShop offers, directly within its installer, an option to randomise the admin folder name instead of keeping the predictable /admin path. This isn’t a third-party extension to install separately: it’s a native, documented feature offered right from the CMS installation. It obviously doesn’t replace a strong password, but it takes your back office out of the path that bots test first and with no effort, filtering out a meaningful share of the most basic automated attempts. ## Practical habits to put in place 1. **One unique password per service** — The CMS back-office password must never be the same as your inbox, host, or any other account. A password manager can generate and store a strong, distinct password for each one. 2. **Turn on two-factor authentication where it exists** — Many CMS platforms and hosts offer two-factor authentication, which still protects you even if a password alone leaks elsewhere. It’s worth enabling on the most sensitive accesses: back office, hosting, database. 3. **Revoke provider access once a job is done** — Any FTP, SSH or admin access given to an external provider should be disabled, or its password changed, as soon as the work is finished, not only once a problem is spotted. 4. **Apply the principle of least privilege** — A secondary account created for a specific need, such as order management or catalogue updates, shouldn’t have super-administrator rights it doesn’t actually need. 5. **Review active accounts regularly** — The list of admin accounts on a CMS grows over time, with no automatic clean-up. An account forgotten for two years is still a valid way in. ## Related reading - **File permissions on shared hosting** — Another flaw rooted in human oversight rather than code, tied to server configuration. ([/securite/droits-de-fichiers-hebergement-mutualise](/securite/droits-de-fichiers-hebergement-mutualise)) - **Check whether your site is compromised** — Free checks to run before considering a paid audit. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis)) - **Security and cleanup of a hacked site** — The full service if access to your store has already been compromised. ([/services/securite](/services/securite)) ## FAQ ### How do I know if my password has already leaked elsewhere? Some public services let you check whether an email address appears in a known data breach. If it does, every password reused on other accounts needs changing, not just the one for the affected service. ### Should I change the admin password after every provider job? Not necessarily if they used a dedicated, revocable account, but yes if they shared an existing one. The safest approach is always creating a named, temporary access for each external contributor. ### Does two-factor authentication slow down my daily work? Adding one extra step to logging in takes a few seconds, on an access you rarely use several times a day. The trade-off is heavily in its favour given what it prevents. ### Is renaming the admin folder enough to secure my site? No, it’s a complementary measure that reduces the most basic automated attempts, not a protection against an attacker specifically targeting your store or one who already holds valid credentials. ### How many admin accounts should my store have? The minimum needed for actual activity. Every extra account, especially with elevated rights, is one more door to protect and monitor over time.