Two-Factor Auth, Password Policies and Admin Security for PrestaShop

Your PrestaShop back office is the one door in your store that opens onto everything: customer records, order history, payment configuration, the module manager that can run arbitrary PHP, and a database export button two clicks away. For most attackers it is far more efficient to log into that door with stolen credentials than to find a code vulnerability — and in a large number of stores, the door is held shut by a single password that the owner also uses for their email and a forum account that was breached three years ago. This post is about hardening that one login: the second factor, the password rules, the employee accounts behind it, and the session that stays alive after you walk away from the screen. It is the access-control layer of security. The other layers — file permissions, headers, patching, bot filtering — live in the complete security hardening checklist, and the calmer, non-technical overview is in the plain-English guide for store owners.

Reviewed June 2026 against PrestaShop 1.6, 1.7, 8 and 9 back-office behaviour and current NIST password guidance.

Where admin logins actually leak

Before reaching for tools, it helps to name the specific failures, because the fix for each is different and PrestaShop-specific:

• Credential reuse. The most common breach has nothing to do with PrestaShop code. An admin password leaked from an unrelated service gets tried against your AdminLogin page by an automated tool. The password was never "cracked" — it was looked up.
• Shared accounts. One admin@ login used by three people means the activity log attributes every change to the same row, and you cannot revoke one person's access without locking out the rest.
• Over-permissioned staff. A packing clerk with SuperAdmin rights is a SuperAdmin-sized hole if their laptop is phished — they had no business reaching the module manager in the first place.
• No second factor. A password alone is a single point of failure. Phishing, a keylogger, or one reused credential is enough.
• Sessions that never end. A back office left open on a shared or stolen machine is an authenticated session anyone can drive.

Everything below maps one fix to one of these. None of it requires touching core files.

Two-factor authentication on the PrestaShop back office

Two-factor authentication splits login into something you know (the password) and something you have (a code from your phone). Steal one and you still cannot pass the other. In PrestaShop the usual route to back-office 2FA is a trusted security module or an external access-control layer in front of the login — so the first thing to settle is how you will add it, not just where to click.

How back-office 2FA actually gets added

Do not assume the core ships a ready-made two-factor toggle for your version. In general, PrestaShop 1.6, 1.7 and 8 need a trusted third-party module or an external access-control layer to put a second factor on the back office. Only treat 2FA as "native" where you have verified it for your exact target version against the official documentation for that release — a feature present in one minor version is not proof it exists in the one you are running.

The practical options, in rough order of effort:

• A trusted admin-security module that adds TOTP (the rotating six-digit code from an authenticator app such as Google Authenticator, Authy, Microsoft Authenticator, 1Password, or KeePass with a TOTP plugin). This is the most common route and the only one that gives a true per-employee app-based second factor.
• An external access-control layer — an SSO/identity proxy or a WAF/reverse-proxy that challenges for a second factor before the request ever reaches PrestaShop. This protects the login surface without touching core at all.
• IP allow-listing (below) as a compensating control where you cannot deploy either of the above — not a true second factor, but it shrinks the attack surface dramatically.

Turning it on

Whichever route you take, the setup steps live in that module's or proxy's own configuration, not a fixed core screen — so follow the instructions for the specific tool you deploy. For an authenticator-app (TOTP) factor the flow is typically:

• Enable the second factor for your own account in the module's or proxy's settings.
• Scan the QR code with your authenticator app, then type the current code back in to prove the clock is synced. A well-built tool will not finalise the setting until you confirm that code, so you cannot lock yourself out with a mis-scanned secret.
• Save, then test it: log out and back in. You should be asked for the rotating code after the password.

Two operational notes that save real grief. First, TOTP depends on the phone and server clocks agreeing within a small window; if codes are rejected, check that your server time is correct (NTP) before assuming the feature is broken. Second, if your 2FA module or proxy provides recovery/backup codes, store them somewhere outside the phone — a password manager entry, not a sticky note. If it does not, document its own recovery procedure in advance, because a lost or wiped phone with no fallback can mean a database-level intervention (clearing the relevant 2FA columns, often on your ps_employee row) to regain access.

Make it mandatory, not optional

One employee without 2FA is the weak link the whole chain hangs from: an attacker who lands in any account has a foothold to escalate. Whatever tool you use typically enables the second factor per person rather than forcing it account-wide, so "mandatory" is a policy you enforce by checking every active employee has it on. If you run several employees and want enrolment enforced (new staff cannot operate until they set it up), look for a module or access-control layer that supports enforced enrolment. On 1.6 and early 1.7 especially, a module or external layer is the route short of locking the login down by IP.

Password policy that matches current guidance

The goal is not "complex" passwords, it is passwords that cannot be guessed, reused, or sprayed. Modern guidance (NIST and others) has moved away from the old complexity-and-rotation theatre toward length and uniqueness.

The practical instruction for staff is short: every back-office account uses a unique, randomly generated password held in a manager (Bitwarden, 1Password, KeePass). A 20-character random string is both stronger and easier to live with than a "clever" memorable one, because nobody has to type or remember it. how PrestaShop stores that password depends on your version: modern releases use a strong password-hashing algorithm (the cost-factored hashing behind PrestaShop\PrestaShop\Core\Crypto\Hashing), so a database leak does not hand over the plaintext — but legacy 1.6 used a weaker, cookie-key-based scheme. If you are still on 1.6, treat its stored hashes as low-value protection: plan an upgrade or migration so passwords are re-hashed with the modern algorithm, and in the meantime lean hard on unique, strong passwords. Either way, the hashing is worthless if the password was admin123 and lives in a public wordlist.

One PrestaShop-specific control worth knowing: the password-reset flow is throttled by the PS_PASSWD_TIME_BACK configuration value (minutes between back-office reset requests), so an attacker cannot spam reset emails. You rarely need to touch it, but it is there.

Employee accounts: one person, one login, least privilege

This is the failure that quietly undermines every other control. PrestaShop's permission model is genuinely capable — the problem is almost always that it is left wide open.

One account per human

Every person gets their own employee record under Advanced Parameters → Team → Employees. This buys you three things at once: an audit trail that names who did what (PrestaShop logs actions against the acting employee), the ability to deactivate one leaver without changing anyone else's password, and per-person 2FA. Shared logins forfeit all three.

Profiles and the principle of least privilege

Permissions in PrestaShop are not set per employee — they are set on a Profile (under Advanced Parameters → Team → Permissions), and each employee is assigned a profile. Build profiles that match real roles and the View / Add / Edit / Delete grid does the rest:

The two rules that matter: keep the SuperAdmin profile down to the owner and at most one trusted technical lead, and remember that the Modules permission is effectively code-execution rights — anyone who can install a module can run PHP on your server, so treat it as the crown-jewel permission it is, not a convenience to hand out.

Locking down the login surface itself

Two factors protect the credentials; these protect the door they open.

Keep the admin folder name random

PrestaShop installs the back office into a randomised directory (something like /admin47ab9c/) precisely so bots cannot find it by guessing /admin or /backoffice. Keep it random. If yours was renamed to something predictable during a migration, rename the folder on disk and PrestaShop picks up the new path automatically — obscurity is not a security control on its own, but it removes you from the firehose of automated scans that hammer the obvious paths.

Throttle and watch failed logins

Brute-force and credential-stuffing tools depend on being able to try thousands of guesses quickly. Two defences apply: at the application edge, put a challenge on the login form so automated tools stall — covered in reCAPTCHA for PrestaShop. At the network edge, restrict who can even reach the login. If your team logs in from a fixed office IP or a VPN, an .htaccess or firewall allow-list on the admin directory blocks every other source outright, valid password or not — that and the other server-level rules live in PrestaShop .htaccess security and performance rules. Either way, review the failed-login pattern: a burst of failures from one IP against one employee is an attack in progress.

# Apache 2.4, inside the randomized back-office directory
Require ip 203.0.113.10
Require ip 198.51.100.0/24

The Total Defender blocked-attempts screen lists entries by type, reason, IP address and date, and reports no blocked attempts in the last 24 hours.

Session security: the part everyone forgets

You can do everything above and still hand an attacker an authenticated session if the back office stays open and logged in on an unattended machine. Three controls close that:

• Idle timeout. PrestaShop ages out back-office sessions based on the PS_COOKIE_LIFETIME_BO setting (the admin cookie lifetime). Keep it tight enough that a walked-away screen logs itself out — short for shared workstations, longer only where the machine is genuinely private.
• HTTPS-only admin. The back office must be reached over HTTPS so the session cookie cannot be sniffed on a café or hotel network. If your store is not yet fully on HTTPS, fix that first — the how-to is setting up SSL and HTTPS on PrestaShop.
• Secure, HttpOnly cookies. Once the site is HTTPS-wide, the admin session cookie should carry the Secure and HttpOnly flags so it is never sent in clear text and cannot be read by JavaScript — a stolen cookie is a bypassed 2FA, so this is not optional.

You can verify the current back-office cookie lifetime directly from the database; the value is stored in days:

SELECT name, value
FROM ps_configuration
WHERE name IN ('PS_COOKIE_LIFETIME_BO', 'PS_PASSWD_TIME_BACK');

Monitor the back office, not just the front

PrestaShop logs some back-office events and errors, and that log is a useful early-warning signal — but treat it as a partial record, not a full audit trail or SIEM. The in-app log will surface things like a new employee account you did not create, a sudden permission change, or an unexpected edit to payment configuration. It does not, on its own, give you reliable login-by-IP or country-aware monitoring: catching "a login at 04:00 from a country you do not operate in" usually means correlating server access logs, a dedicated security module, or your WAF/reverse-proxy logs, where the source IP is recorded. Build a habit of skimming the in-app log — monthly at minimum, weekly if you have staff turnover — and pair it with whichever server-level log gives you the authentication source. If you already suspect you are past the warning stage and into an active compromise, stop reading hardening tips and follow the incident playbook in data breach response: what to do if your store gets hacked.

If you cannot deploy a 2FA module

Plenty of stores are stuck on a frozen setup — an old version held in place by a legacy theme, a legacy module, or a PHP version that an upgrade would break — where adding a security module is awkward. You are not out of options: a trusted module can add the second factor where it fits, an external access-control layer can sit in front of the login, IP allow-listing can ring-fence the back office, and the rest of the access-control advice here applies unchanged. The wider strategy for hardening a store you genuinely cannot move yet — virtual patching and compensating controls — is its own subject in advanced PrestaShop hardening for stores you can't upgrade yet.

A 10-minute admin lockdown, in order

• Enable 2FA on your own SuperAdmin account right now via your security module or access-control layer, and confirm a recovery option is saved off-device.
• List every active employee. Disable shared logins; give each human their own account.
• Open Permissions and demote anyone who does not need SuperAdmin. Verify only 1–2 people hold it, and that Modules access is tightly held.
• Walk each remaining person through enabling their own 2FA.
• Confirm every admin password is unique and manager-generated — rotate any that are not.
• Check the admin folder name is still random, not /admin.
• Tighten the back-office cookie lifetime so idle sessions log out.
• Confirm the admin is HTTPS-only and the session cookie is Secure + HttpOnly.
• Read one month of admin logs. Note what "normal" looks like so the abnormal stands out next time.

Frequently asked questions

Does PrestaShop have built-in two-factor authentication for the back office?

Don't assume it for your version. PrestaShop 1.6, 1.7 and 8 generally need a trusted admin-security module or an external access-control layer (an SSO/identity proxy, or a WAF in front of the login) to put a second factor on the back office. Only treat 2FA as native where you've verified it against the official documentation for your exact release — a feature in one minor version isn't proof it exists in the one you're running.

What happens if I lose the phone with my authenticator app?

If your 2FA tool offers recovery or backup codes, you store them off the phone (a password-manager entry) and use one to get back in. If it doesn't, you fall back to its documented recovery procedure, which on many setups means a database-level intervention — clearing the relevant 2FA columns on your ps_employee row to disable the second factor for that account so you can log in and re-enrol. That's why you sort out the recovery path before you turn 2FA on, not after.

Should I force my admin passwords to expire every 90 days?

No. Current guidance (NIST and others) dropped scheduled rotation because it pushes people to Summer2024! → Summer2025!, which is weaker, not stronger. Change a password only on suspected compromise. Put the effort into length and uniqueness instead: a 16+ character, randomly generated, never-reused string from a password manager, one per account.

Is renaming the admin folder actually worth it?

It's worth keeping random, not worth obsessing over. PrestaShop already installs the back office into a randomised directory so bots can't find it by guessing /admin or /backoffice; if a migration left yours predictable, rename the folder on disk and PrestaShop picks up the new path. It's obscurity, not a security control — it removes you from the firehose of automated scans, but it earns its keep only alongside 2FA, strong passwords, and login throttling.

How do I stop brute-force and credential-stuffing attacks on the login?

Layer two edges. At the application edge, put a challenge on the login form (reCAPTCHA) so automated tools stall. At the network edge, restrict who can reach the login at all — if your team logs in from a fixed office IP or VPN, an .htaccess or firewall allow-list on the admin directory turns away every other source, valid password or not. Neither replaces 2FA, which is what saves you when a real password leaks.

So what does this actually buy you?

Run the list and the economics of attacking your store change. Credential stuffing fails at the second factor. A phished password is useless without the phone. A compromised packing-clerk account cannot reach the module manager. A walked-away laptop logs itself out. None of it requires a developer, a core edit, or an upgrade you cannot afford — it is back-office configuration and a password manager. We build security modules and run shops ourselves, so the honest framing is this: the back office is where a breach goes from inconvenient to catastrophic, and access control is the cheapest, highest-impact hour you will spend on it. When you are ready to harden the layers underneath the login — files, headers, patching, bot traffic — the complete hardening checklist is the map for the rest.