Mots de passe clients dans PrestaShop : comment ils sont stockés et ce qu'il ne faut pas faire

Un client appelle parce qu'il ne se souvient plus de son mot de passe et vous demande de le lui donner. Vous ne pouvez pas, et c'est très bien ainsi : la boutique ne le connaît pas. Ce que PrestaShop enregistre dans la base de données n'est pas le mot de passe, mais une empreinte calculée à partir de lui, à partir de laquelle on ne peut pas revenir en arrière. Comprendre le fonctionnement de cette empreinte vous évite des erreurs lors de la migration de clients, de l'import de comptes et du support.

Ce que la boutique stocke réellement

Lorsqu'un client crée son compte, PrestaShop fait passer le mot de passe par une fonction de hachage : un calcul qui, à partir d'un texte, produit une chaîne de longueur fixe. Le même mot de passe donne toujours un résultat vérifiable, mais on ne peut pas retrouver le mot de passe à partir du résultat. À la connexion, la boutique recalcule le hachage de ce que saisit le client et le compare à celui qui est enregistré. S'ils correspondent, il est connecté.

Le hachage se trouve dans la colonne passwd de la table des clients (ps_customer avec le préfixe habituel) et, pour les employés, dans ps_employee. Voir cette colonne ne donne pas le mot de passe, mais permet de tester des mots de passe candidats en dehors de votre serveur, sans limite de tentatives. C'est pourquoi l'algorithme utilisé compte autant.

Comment cela a évolué selon la version

PrestaShop 1.6 et antérieures

Le hachage était un MD5 du mot de passe concaténé à la clé de cookies de l'installation. MD5 se calcule extrêmement vite, et ce qui est une qualité dans d'autres contextes est ici un défaut : un ordinateur ordinaire teste des quantités énormes de candidats par seconde. Si quelqu'un obtient la base de données et la clé de cookies du fichier de configuration, les mots de passe faibles tombent tout de suite.

PrestaShop 1.7, 8 et 9

Depuis la 1.7, PrestaShop utilise bcrypt via les fonctions de mots de passe de PHP. Bcrypt est volontairement lent et utilise un sel différent pour chaque utilisateur, ce qui rend les tentatives beaucoup plus coûteuses. La boutique sait toujours vérifier les anciens hachages : lorsqu'un client avec un hachage de la 1.6 se connecte correctement, PrestaShop le recalcule avec le nouvel algorithme et l'enregistre. Les clients qui ne reviennent jamais conservent l'ancien hachage.

À partir de PrestaShop 8, vous disposez en outre d'une politique de mots de passe configurable dans les paramètres de sécurité de la boutique (longueur et niveau de robustesse exigé), qui s'applique aux nouveaux mots de passe.

Migrer des clients depuis une autre plateforme

Lors d'un passage depuis WooCommerce, Magento, Shopify ou un autre PrestaShop, la question est toujours la même : les clients pourront-ils se connecter avec leur mot de passe ? Cela dépend du format du hachage d'origine :

• Si l'origine utilise du bcrypt standard, le hachage est généralement compatible et il suffit de le copier, à condition de le tester d'abord avec plusieurs comptes réels sur la copie de test.
• Si elle utilise un format propre (hachages avec des préfixes de la plateforme, plusieurs passes d'un autre algorithme), PrestaShop ne saura pas le vérifier. Les options sont un module passerelle qui valide l'ancien format à la première connexion et le convertit, ou demander à tous les clients de réinitialiser leur mot de passe.
• Si l'origine ne vous fournit pas les hachages (certaines plateformes fermées ne les exportent pas), il ne reste que la réinitialisation.

Si vous devez imposer la réinitialisation, préparez-la : un e-mail expliquant le changement de boutique, envoyé par lots depuis un serveur de messagerie qui ne finit pas en spam, et une page de récupération qui fonctionne sur mobile. Beaucoup de clients arriveront depuis l'e-mail d'une commande et non depuis cet avis.

Réinitialiser les mots de passe sans créer de failles

Le bon parcours est celui que propose PrestaShop : le client demande la récupération, reçoit un lien avec un code à usage unique qui expire, et choisit un nouveau mot de passe. Les erreurs apparaissent quand on essaie de prendre des raccourcis :

• Définir vous-même un mot de passe et le dicter par téléphone ou l'envoyer par e-mail. Il reste écrit dans des endroits que vous ne contrôlez pas et le client le change rarement.
• Utiliser le même mot de passe pour tous lors d'un import (« Boutique2024 » pour chaque client migré). C'est le premier que n'importe qui essaiera.
• Envoyer les mots de passe en clair dans l'e-mail de bienvenue. Certains anciens modules le font. Vérifiez les modèles d'e-mail et retirez cette variable.
• Demander au client son mot de passe pour entrer dans son compte et voir ce qui se passe. Si vous avez besoin de voir ce qu'il voit, il existe des moyens de le faire sans.

Ce qu'il ne faut jamais faire

1. Stocker les mots de passe en clair ou chiffrés de façon réversible « au cas où », dans une table à part, un CSV ou un champ de notes. Un module tiers qui fait cela transforme n'importe quelle fuite en catastrophe.
2. Exporter la table des clients complète pour l'envoyer à une agence ou à un prestataire. Exportez uniquement les colonnes nécessaires et jamais passwd.
3. Laisser des sauvegardes de la base de données dans un dossier public du serveur. Un .sql à la racine contient tous les hachages et la clé pour les attaquer.
4. Utiliser la même clé de cookies sur la copie de test et en production et laisser la copie accessible depuis Internet sans mot de passe.
5. Écrire dans les journaux de débogage le contenu des formulaires de connexion. Cela arrive plus souvent qu'on ne le croit avec des modules en mode débogage.

Si vous soupçonnez une fuite

Si quelqu'un a eu accès à la base de données, agissez comme si les hachages étaient dans la nature :

• Fermez d'abord la porte d'entrée : module vulnérable, identifiants FTP ou du panneau d'hébergement, sauvegarde publique.
• Changez le mot de passe de la base de données et ceux de tous les employés.
• Évaluez avec un professionnel si vous devez notifier la violation à l'autorité de protection des données et aux personnes concernées. Le RGPD impose d'évaluer le risque et, selon le cas, de notifier.
• Invitez les clients à changer leur mot de passe, surtout s'ils le réutilisent sur d'autres services. Si le hachage datait de la 1.6, la recommandation est plus urgente.

Pourquoi mettre à jour protège aussi les mots de passe

Une boutique encore en 1.6 stocke les mots de passe de façon faible, et continuera tant qu'elle ne sera pas migrée. De plus, les violations qui exposent la base de données arrivent presque toujours par des modules non mis à jour. Maintenir PrestaShop, PHP et les modules à jour n'est pas qu'une question de nouvelles fonctions : cela détermine l'ampleur des dégâts d'une fuite quand elle se produit.

Comment le résoudre dans PrestaShop

RKR Security Alert ne gère pas les mots de passe, mais surveille ce qui précède généralement une fuite. Son audit signale les sauvegardes .sql ou .zip accessibles à la racine, les fichiers de configuration aux permissions trop larges qui exposent les identifiants de la base de données, le mode développement et display_errors activés en production, ainsi que les comptes administrateur inactifs. Il détecte également les créations et modifications d'employés même lorsqu'elles sont faites en SQL direct, les connexions au back-office depuis de nouvelles IP et les web shells dans les fichiers, et vous alerte par Telegram sans envoyer aucun fichier hors du serveur.