Password dei clienti in PrestaShop: come vengono salvate e cosa non fare

Un cliente chiama perché non ricorda la password e ti chiede di dirgliela. Non puoi, ed è giusto così: il negozio non la conosce. Quello che PrestaShop salva nel database non è la password, ma un'impronta calcolata a partire da essa, da cui non si può tornare indietro. Capire come funziona questa impronta ti evita errori quando migri clienti, importi account e fai assistenza.

Cosa salva davvero il negozio

Quando un cliente crea il suo account, PrestaShop passa la password attraverso una funzione di hash: un calcolo che, partendo da un testo, produce una stringa di lunghezza fissa. La stessa password dà sempre un risultato verificabile, ma dal risultato non si può ricavare la password. Al login il negozio ricalcola l'hash di ciò che digita il cliente e lo confronta con quello salvato. Se coincidono, entra.

L'hash si trova nella colonna passwd della tabella dei clienti (ps_customer con il prefisso abituale) e, per i dipendenti, in ps_employee. Chi vede quella colonna non ottiene la password, ma può provare password candidate fuori dal tuo server, senza limite di tentativi. Per questo conta molto quale algoritmo si usa.

Come è cambiato a seconda della versione

PrestaShop 1.6 e precedenti

L'hash era un MD5 della password concatenata con la chiave dei cookie dell'installazione. MD5 è velocissimo da calcolare e questo, che in altri contesti è un pregio, qui è un difetto: un computer qualsiasi prova enormi quantità di candidati al secondo. Se qualcuno ottiene il database e la chiave dei cookie dal file di configurazione, le password deboli cadono subito.

PrestaShop 1.7, 8 e 9

Dalla 1.7 si usa bcrypt tramite le funzioni per le password di PHP. Bcrypt è lento di proposito e usa un sale diverso per ogni utente, quindi provare password costa molto di più. Il negozio continua a saper verificare gli hash vecchi: quando un cliente con un hash della 1.6 accede correttamente, PrestaShop lo ricalcola con il nuovo algoritmo e lo salva. I clienti che non tornano mai conservano l'hash vecchio.

Da PrestaShop 8 hai inoltre una politica delle password configurabile nei parametri di sicurezza del negozio (lunghezza e livello di robustezza richiesto), che si applica alle nuove password.

Migrare clienti da un'altra piattaforma

Quando passi da WooCommerce, Magento, Shopify o un altro PrestaShop, la domanda è sempre la stessa: i clienti potranno entrare con la loro password? Dipende dal formato dell'hash di origine:

• Se l'origine usa bcrypt standard, l'hash di solito è compatibile e basta copiarlo, purché tu lo provi prima con diversi account reali nella copia di prova.
• Se usa un formato proprio (hash con prefissi della piattaforma, più passaggi di un altro algoritmo), PrestaShop non saprà verificarlo. Le opzioni sono un modulo ponte che validi il vecchio formato al primo accesso e lo converta, oppure chiedere a tutti i clienti di reimpostare la password.
• Se l'origine non ti fornisce gli hash (alcune piattaforme chiuse non li esportano), resta solo la reimpostazione.

Se devi imporre la reimpostazione, preparala: un'email che spieghi il cambio di negozio, inviata a scaglioni da un server di posta che non finisca nello spam, e una pagina di recupero che funzioni da mobile. Molti clienti arriveranno dall'email di un ordine e non da quell'avviso.

Reimpostare le password senza aprire falle

Il flusso corretto è quello di PrestaShop: il cliente chiede il recupero, riceve un link con un codice monouso che scade e sceglie una nuova password. Gli errori nascono quando si cerca una scorciatoia:

• Impostare tu una password e dettarla al telefono o inviarla per email. Rimane scritta in posti che non controlli e il cliente raramente la cambia.
• Usare la stessa password per tutti in un'importazione («Negozio2024» per ogni cliente migrato). È la prima che chiunque proverà.
• Inviare le password in chiaro nell'email di benvenuto. Alcuni moduli vecchi lo fanno. Controlla i modelli di email e togli quella variabile.
• Chiedere al cliente la password per entrare nel suo account e vedere cosa gli succede. Se devi vedere ciò che vede lui, ci sono modi per farlo senza.

Cosa non fare mai

1. Salvare le password in chiaro o cifrate in modo reversibile «per sicurezza», in una tabella propria, in un CSV o in un campo note. Un modulo di terze parti che lo faccia trasforma qualsiasi fuga in un disastro.
2. Esportare la tabella clienti completa per inviarla a un'agenzia o a un fornitore. Esporta solo le colonne che servono e mai passwd.
3. Lasciare dump del database in una cartella pubblica del server. Un .sql nella root contiene tutti gli hash e la chiave per attaccarli.
4. Usare la stessa chiave dei cookie nella copia di prova e in produzione e lasciare la copia raggiungibile da Internet senza password.
5. Scrivere nei log di debug il contenuto dei moduli di accesso. Succede più spesso di quanto sembri con moduli in modalità debug.

Se sospetti una fuga

Se qualcuno ha avuto accesso al database, comportati come se gli hash fossero già fuori:

• Chiudi prima la via d'ingresso: modulo vulnerabile, credenziali FTP o del pannello, dump pubblico.
• Cambia la password del database e quelle di tutti i dipendenti.
• Valuta con un professionista se devi notificare la violazione all'autorità per la protezione dei dati e agli interessati. Il GDPR impone di valutare il rischio e, a seconda del caso, di notificare.
• Invita i clienti a cambiare la password, soprattutto se la riutilizzano in altri servizi. Se l'hash era della 1.6, la raccomandazione è più urgente.

Perché aggiornare protegge anche le password

Un negozio fermo alla 1.6 salva le password in modo debole, e continuerà a farlo finché non verrà migrato. Inoltre, le violazioni che espongono il database arrivano quasi sempre da moduli non aggiornati. Tenere aggiornati PrestaShop, PHP e moduli non è solo una questione di nuove funzioni: decide quanto danno fa una fuga quando avviene.

Come risolverlo in PrestaShop

RKR Security Alert non gestisce le password, ma sorveglia ciò che di solito precede una fuga. La sua verifica segnala backup .sql o .zip raggiungibili nella root, file di configurazione con permessi troppo larghi che espongono le credenziali del database, modalità sviluppo e display_errors attivi in produzione e account amministratore inattivi. Rileva inoltre creazioni e modifiche di dipendenti anche se fatte con SQL diretto, accessi al back-office da IP nuovi e web shell nei file, e ti avvisa via Telegram senza inviare alcun file fuori dal server.