Autenticazione a due fattori, criteri per le password e sicurezza dell'amministrazione PrestaShop

Il back office PrestaShop è l'unica porta del tuo negozio che apre l'accesso a tutto: dati dei clienti, storico degli ordini, configurazione dei pagamenti, gestore dei moduli in grado di eseguire PHP arbitrario e un pulsante per esportare il database a due clic di distanza. Per la maggior parte degli attaccanti è molto più efficiente entrare da quella porta con credenziali rubate che cercare una vulnerabilità nel codice — e in moltissimi negozi quella porta è tenuta chiusa da una sola password che il proprietario usa anche per l'email e per un account di forum violato tre anni fa. Questo articolo spiega come rafforzare proprio quel login: il secondo fattore, le regole sulle password, gli account dipendenti che lo usano e la sessione che rimane attiva quando ti allontani dallo schermo. È il livello di sicurezza del controllo degli accessi. Gli altri livelli — permessi dei file, header, patch, filtro dei bot — sono nella checklist completa di hardening della sicurezza, mentre la panoramica più tranquilla e non tecnica è nella guida in linguaggio semplice per i titolari di negozi.

Revisionato a giugno 2026 in base al comportamento del back office di PrestaShop 1.6, 1.7, 8 e 9 e alle linee guida NIST attuali sulle password.

Da dove trapelano davvero gli accessi amministrativi

Prima di cercare strumenti, conviene dare un nome agli errori specifici, perché la soluzione per ciascuno è diversa e specifica per PrestaShop:

• Riutilizzo delle credenziali. La violazione più comune non ha nulla a che fare con il codice PrestaShop. Una password admin trapelata da un servizio non collegato viene provata sulla tua pagina AdminLogin da uno strumento automatico. La password non è mai stata "craccata" — è stata cercata in un elenco.
• Account condivisi. Un login admin@ usato da tre persone significa che il registro attività attribuisce ogni modifica alla stessa riga e non puoi revocare l'accesso a una persona senza bloccare anche le altre.
• Personale con troppi permessi. Un addetto all'imballaggio con diritti SuperAdmin diventa una falla grande quanto un SuperAdmin se il suo portatile viene colpito da phishing — in primo luogo non aveva alcun motivo di accedere al gestore dei moduli.
• Nessun secondo fattore. Una password da sola è un singolo punto di fallimento. Phishing, un keylogger o una sola credenziale riutilizzata bastano.
• Sessioni che non scadono mai. Un back office lasciato aperto su una macchina condivisa o rubata è una sessione autenticata che chiunque può usare.

Tutto ciò che segue associa una soluzione a uno di questi problemi. Nulla richiede di toccare i file core.

Autenticazione a due fattori nel back office PrestaShop

L'autenticazione a due fattori divide il login in qualcosa che conosci (la password) e qualcosa che possiedi (un codice dal telefono). Rubane uno e comunque non puoi superare l'altro. In PrestaShop, la strada abituale per aggiungere la 2FA al back office è un modulo di sicurezza affidabile o un livello esterno di controllo degli accessi davanti al login — quindi la prima cosa da decidere è come aggiungerla, non solo dove cliccare.

Come si aggiunge davvero la 2FA al back office

Non dare per scontato che il core includa un interruttore pronto per la doppia autenticazione nella tua versione. In generale, PrestaShop 1.6, 1.7 e 8 richiedono un modulo di terze parti affidabile o un livello esterno di controllo degli accessi per applicare un secondo fattore al back office. Considera la 2FA "nativa" solo dove l'hai verificata per la tua esatta versione di destinazione nella documentazione ufficiale di quella release — una funzione presente in una minor version non prova che esista in quella che stai usando.

Le opzioni pratiche, grosso modo in ordine di impegno:

• Un modulo affidabile per la sicurezza dell'amministrazione che aggiunge TOTP (il codice rotante a sei cifre di un'app di autenticazione come Google Authenticator, Authy, Microsoft Authenticator, 1Password o KeePass con un plugin TOTP). È la strada più comune e l'unica che offre un vero secondo fattore basato su app per ogni dipendente.
• Un livello esterno di controllo degli accessi — un proxy SSO/identità o un WAF/reverse proxy che richiede un secondo fattore prima ancora che la richiesta raggiunga PrestaShop. Protegge la superficie di login senza toccare affatto il core.
• Una lista di IP consentiti (sotto) come controllo compensativo quando non puoi implementare nessuna delle due opzioni precedenti — non è un vero secondo fattore, ma riduce drasticamente la superficie di attacco.

Attivarla

Qualunque strada tu scelga, i passaggi di configurazione si trovano nelle impostazioni del modulo o del proxy, non in una schermata core fissa — quindi segui le istruzioni dello strumento specifico che installi. Per un fattore tramite app di autenticazione (TOTP), il flusso di solito è questo:

• Abilita il secondo fattore per il tuo account nelle impostazioni del modulo o del proxy.
• Scansiona il codice QR con la tua app di autenticazione, poi inserisci il codice corrente per dimostrare che l'orologio è sincronizzato. Uno strumento ben progettato non finalizza l'impostazione finché non confermi quel codice, così non rischi di chiuderti fuori per un segreto scansionato male.
• Salva, poi verifica: esci e rientra. Dopo la password dovrebbe esserti richiesto il codice rotante.

Due note operative evitano problemi reali. Primo: TOTP dipende dal fatto che gli orologi del telefono e del server coincidano entro una piccola finestra; se i codici vengono rifiutati, controlla che l'ora del server sia corretta (NTP) prima di concludere che la funzione non funzioni. Secondo: se il tuo modulo 2FA o proxy fornisce codici di recupero/backup, conservali fuori dal telefono — in una voce del gestore password, non su un post-it. Se non li fornisce, documenta in anticipo la sua procedura di recupero, perché un telefono perso o cancellato senza alternativa può richiedere un intervento a livello database (cancellando le colonne 2FA pertinenti, spesso nella riga ps_employee) per recuperare l'accesso.

Rendila obbligatoria, non facoltativa

Un solo dipendente senza 2FA è l'anello debole da cui dipende tutta la catena: un attaccante che entra in qualunque account ha già un punto d'appoggio per scalare. Lo strumento che usi di solito abilita il secondo fattore per singola persona, invece di imporlo a tutto l'account, quindi "obbligatorio" è una regola che applichi controllando che ogni dipendente attivo lo abbia abilitato. Se gestisci più dipendenti e vuoi che l'attivazione sia imposta (il nuovo personale non può operare finché non la configura), cerca un modulo o un livello di controllo degli accessi che supporti l'attivazione obbligatoria. Soprattutto su 1.6 e sulle prime 1.7, un modulo o un livello esterno è la strada da seguire, a meno di bloccare il login per IP.

Una policy password allineata alle linee guida attuali

L'obiettivo non sono password "complesse", ma password che non possano essere indovinate, riutilizzate o provate in massa. Le linee guida moderne (NIST e altre) si sono allontanate dal vecchio teatro di complessità e rotazione verso lunghezza e unicità.

L'istruzione pratica per il personale è breve: ogni account del back office usa una password unica, generata casualmente e conservata in un gestore password (Bitwarden, 1Password, KeePass). Una stringa casuale di 20 caratteri è più robusta e anche più semplice da usare rispetto a una password "furba" e memorabile, perché nessuno deve digitarla o ricordarla. Il modo in cui PrestaShop memorizza quella password dipende dalla tua versione: le release moderne usano un algoritmo di hashing robusto (l'hashing con costo regolabile dietro PrestaShop\PrestaShop\Core\Crypto\Hashing), quindi una fuga del database non consegna il testo in chiaro — ma la vecchia 1.6 usava uno schema più debole basato sulla chiave cookie. Se sei ancora su 1.6, considera gli hash memorizzati una protezione di scarso valore: pianifica un aggiornamento o una migrazione in modo che le password vengano sottoposte di nuovo a hashing con l'algoritmo moderno e, nel frattempo, punta con decisione su password uniche e solide. In ogni caso, l'hashing non vale nulla se la password era admin123 e compare in una wordlist pubblica.

Un controllo specifico di PrestaShop che vale la pena conoscere: il flusso di reset password è limitato dal valore di configurazione PS_PASSWD_TIME_BACK (minuti tra le richieste di reset del back office), quindi un attaccante non può martellare l'invio di email di reset. Di rado dovrai toccarlo, ma esiste.

Account dipendenti: una persona, un login, privilegio minimo

È l'errore che indebolisce silenziosamente ogni altro controllo. Il modello di permessi di PrestaShop è davvero valido — il problema è quasi sempre che viene lasciato troppo aperto.

Un account per ogni persona

Ogni persona deve avere il proprio record dipendente in Parametri avanzati → Team → Dipendenti. Questo ti dà tre vantaggi insieme: una traccia di audit che indica chi ha fatto cosa (PrestaShop registra le azioni sul dipendente che le esegue), la possibilità di disattivare una persona uscita dall'azienda senza cambiare la password di nessun altro e la 2FA per singola persona. I login condivisi fanno perdere tutti e tre.

Profili e principio del privilegio minimo

In PrestaShop i permessi non si impostano per dipendente — si impostano su un Profilo (in Parametri avanzati → Team → Permessi) e ogni dipendente viene assegnato a un profilo. Crea profili che rispecchino i ruoli reali e la griglia Visualizza / Aggiungi / Modifica / Elimina farà il resto:

Le due regole che contano: limita il profilo SuperAdmin al titolare e al massimo a un responsabile tecnico fidato, e ricorda che il permesso Moduli equivale di fatto a diritti di esecuzione del codice — chiunque possa installare un modulo può eseguire PHP sul tuo server, quindi trattalo come il permesso più prezioso, non come una comodità da distribuire.

Mettere in sicurezza la superficie di login

I due fattori proteggono le credenziali; questi controlli proteggono la porta che aprono.

Mantieni casuale il nome della cartella admin

PrestaShop installa il back office in una directory randomizzata (qualcosa come /admin47ab9c/) proprio perché i bot non possano trovarla provando /admin o /backoffice. Mantienila casuale. Se durante una migrazione è stata rinominata in qualcosa di prevedibile, rinomina la cartella sul disco e PrestaShop rileverà automaticamente il nuovo percorso — l'oscuramento non è un controllo di sicurezza da solo, ma ti toglie dal flusso continuo di scansioni automatiche che martellano i percorsi più ovvi.

Limita e controlla i login falliti

Gli strumenti di brute force e credential stuffing dipendono dalla possibilità di provare rapidamente migliaia di combinazioni. Si applicano due difese: sul perimetro applicativo, inserisci una verifica nel modulo di login in modo che gli strumenti automatici si blocchino — come spiegato in reCAPTCHA per PrestaShop. Sul perimetro di rete, limita chi può raggiungere il login. Se il tuo team accede da un IP fisso dell'ufficio o da una VPN, una lista di indirizzi consentiti tramite .htaccess o firewall sulla directory admin blocca direttamente ogni altra sorgente, password valida o meno — questa e le altre regole a livello server sono in regole .htaccess di sicurezza e performance per PrestaShop. In ogni caso, esamina lo schema dei login falliti: una raffica di errori da un IP contro un dipendente è un attacco in corso.

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

La schermata dei tentativi bloccati di Total Defender elenca le voci per tipo, motivo, indirizzo IP e data e segnala nessun tentativo bloccato nelle ultime 24 ore.

Sicurezza delle sessioni: la parte che tutti dimenticano

Puoi fare tutto quanto sopra e consegnare comunque a un attaccante una sessione autenticata se il back office resta aperto e connesso su una macchina incustodita. Tre controlli chiudono questa falla:

• Timeout di inattività. PrestaShop fa scadere le sessioni del back office in base all'impostazione PS_COOKIE_LIFETIME_BO (durata del cookie admin). Mantienila abbastanza breve perché uno schermo lasciato incustodito si disconnetta da solo — più breve per postazioni condivise, più lunga solo dove la macchina è davvero privata.
• Admin solo HTTPS. Il back office deve essere raggiunto via HTTPS, così il cookie di sessione non può essere intercettato su una rete di un bar o di un hotel. Se il tuo negozio non è ancora interamente su HTTPS, sistema prima quello — la guida è configurare SSL e HTTPS su PrestaShop.
• Cookie sicuri e HttpOnly. Quando tutto il sito usa HTTPS, il cookie di sessione admin dovrebbe avere i flag Secure e HttpOnly, così non viene mai inviato in chiaro e non può essere letto da JavaScript — un cookie rubato equivale a una 2FA aggirata, quindi non è opzionale.

Puoi verificare l'attuale durata del cookie del back office direttamente dal database; il valore è memorizzato in giorni:

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

Monitora il back office, non solo il front office

PrestaShop registra alcuni eventi ed errori del back office e quel log è un utile segnale di allarme precoce — ma consideralo un registro parziale, non una traccia di audit completa o un SIEM. Il log interno all'applicazione farà emergere elementi come un nuovo account dipendente che non hai creato, una modifica improvvisa dei permessi o un intervento inatteso sulla configurazione dei pagamenti. Da solo, però, non offre un monitoraggio affidabile dei login per IP o sensibile al paese: intercettare "un login alle 04:00 da un paese in cui non operi" di solito significa correlare i log di accesso del server, un modulo di sicurezza dedicato o i log del WAF/reverse proxy, dove l'IP sorgente viene registrato. Prendi l'abitudine di scorrere il log interno — almeno mensilmente, settimanalmente se hai turnover del personale — e affiancalo al log a livello server che ti indica l'origine dell'autenticazione. Se sospetti già di aver superato la fase di avviso e di essere dentro una compromissione attiva, smetti di leggere consigli di hardening e segui il playbook per incidenti in risposta a una violazione dei dati: cosa fare se il tuo negozio viene violato.

Se non puoi installare un modulo 2FA

Molti negozi sono bloccati su una configurazione congelata — una vecchia versione mantenuta in vita da un tema legacy, un modulo legacy o una versione PHP che un aggiornamento romperebbe — dove aggiungere un modulo di sicurezza è complicato. Non sei senza opzioni: un modulo affidabile può aggiungere il secondo fattore dove si integra, un livello esterno di controllo degli accessi può stare davanti al login, una lista di IP consentiti può recintare il back office, e il resto dei consigli sul controllo degli accessi qui resta valido senza modifiche. La strategia più ampia per mettere in sicurezza un negozio che davvero non puoi ancora aggiornare — patching virtuale e controlli compensativi — è trattata a parte in hardening avanzato di PrestaShop per negozi che non puoi ancora aggiornare.

Blocco dell'amministrazione in 10 minuti, in ordine

• Abilita subito la 2FA sul tuo account SuperAdmin tramite il modulo di sicurezza o il livello di controllo degli accessi, e conferma che un'opzione di recupero sia salvata fuori dal dispositivo.
• Elenca ogni dipendente attivo. Disabilita i login condivisi; assegna a ogni persona il proprio account.
• Apri Permessi e abbassa i privilegi di chi non ha bisogno del SuperAdmin. Verifica che solo 1-2 persone lo detengano e che l'accesso ai Moduli sia strettamente controllato.
• Guida ogni altra persona nell'attivazione della propria 2FA.
• Conferma che ogni password admin sia unica e generata da un gestore password — ruota quelle che non lo sono.
• Controlla che il nome della cartella admin sia ancora casuale, non /admin.
• Riduci la durata del cookie del back office affinché le sessioni inattive vengano disconnesse.
• Conferma che l'admin sia accessibile solo via HTTPS e che il cookie di sessione sia Secure + HttpOnly.
• Leggi un mese di log amministrativi. Annota com'è il "normale" così l'anomalo sarà più evidente la prossima volta.

Domande frequenti

PrestaShop ha l'autenticazione a due fattori integrata per il back office?

Non darlo per scontato per la tua versione. PrestaShop 1.6, 1.7 e 8 in genere richiedono un modulo affidabile per la sicurezza dell'amministrazione o un livello esterno di controllo degli accessi (un proxy SSO/identità o un WAF davanti al login) per aggiungere un secondo fattore al back office. Considera la 2FA nativa solo se l'hai verificata nella documentazione ufficiale della tua release esatta — una funzione presente in una minor version non prova che esista in quella che stai usando.

Cosa succede se perdo il telefono con l'app di autenticazione?

Se il tuo strumento 2FA offre codici di recupero o backup, li conservi fuori dal telefono (in una voce del gestore password) e ne usi uno per rientrare. Se non li offre, segui la procedura di recupero documentata, che in molte configurazioni significa un intervento a livello database — cancellare le colonne 2FA pertinenti nella tua riga ps_employee per disabilitare il secondo fattore di quell'account, così puoi accedere e registrarlo di nuovo. Ecco perché il percorso di recupero si prepara prima di attivare la 2FA, non dopo.

Dovrei obbligare le password admin a scadere ogni 90 giorni?

No. Le linee guida attuali (NIST e altre) hanno abbandonato la rotazione programmata perché spinge le persone a passare da Summer2024! → Summer2025!, che è più debole, non più forte. Cambia una password solo in caso di sospetta compromissione. Metti invece l'impegno su lunghezza e unicità: una stringa di 16+ caratteri, generata casualmente, mai riutilizzata, proveniente da un gestore password, una per account.

Rinominare la cartella admin serve davvero?

Vale la pena mantenerla casuale, non ossessionarsene. PrestaShop installa già il back office in una directory randomizzata perché i bot non possano trovarla provando /admin o /backoffice; se una migrazione l'ha resa prevedibile, rinomina la cartella sul disco e PrestaShop rileverà il nuovo percorso. È oscuramento, non un controllo di sicurezza — ti toglie dal flusso continuo delle scansioni automatiche, ma ha valore solo insieme a 2FA, password solide e limitazione dei tentativi di login.

Come fermo gli attacchi brute force e credential stuffing sul login?

Lavora su due fronti. Sul perimetro applicativo, inserisci una verifica nel modulo di login (reCAPTCHA) in modo che gli strumenti automatici si blocchino. Sul perimetro di rete, limita chi può raggiungere il login — se il tuo team accede da un IP fisso dell'ufficio o da una VPN, una lista di indirizzi consentiti tramite .htaccess o firewall sulla directory admin respinge ogni altra sorgente, password valida o meno. Nessuno dei due sostituisce la 2FA, che è ciò che ti salva quando trapela una password reale.

Quindi, in concreto, cosa ottieni?

Esegui la lista e cambiano i conti per chi attacca il tuo negozio. Il credential stuffing si ferma al secondo fattore. Una password carpita con phishing è inutile senza il telefono. Un account compromesso di un addetto all'imballaggio non può raggiungere il gestore dei moduli. Un portatile lasciato incustodito si disconnette da solo. Nulla di tutto questo richiede uno sviluppatore, una modifica al core o un aggiornamento che non puoi permetterti — è configurazione del back office e un gestore password. Costruiamo moduli di sicurezza e gestiamo negozi anche noi, quindi la sintesi onesta è questa: il back office è il punto in cui una violazione passa da fastidiosa a catastrofica, e il controllo degli accessi è l'ora di lavoro più economica e ad alto impatto che puoi dedicargli. Quando sei pronto a rafforzare gli strati sotto il login — file, header, patch, traffico bot — la checklist completa di hardening è la mappa per il resto.