Cambiar la contraseña de un usuario de PrestaShop desde MySQL
Pongámonos en situación.
Estamos trabajando con una tienda PrestaShop, no podemos acceder al panel de administración y, además, estamos trabajando en un entorno local.
Si tenemos acceso a los archivos de la instalación y a su base de datos, existen diferentes formas de recuperar el acceso. El procedimiento, eso sí, depende bastante de la versión de PrestaShop que estemos utilizando.
Importante antes de empezar
Este artículo conserva el procedimiento original para versiones antiguas de PrestaShop, pero también veremos cómo abordar el problema en versiones modernas. No debemos ejecutar una consulta antigua sobre una instalación actual sin comprobar antes la versión y el sistema de autenticación.
Antes de modificar nada: backup
Como siempre que voy a modificar directamente una base de datos, lo primero es hacer una copia de seguridad.
No importa que la consulta parezca sencilla. Estamos modificando directamente los datos de autenticación de una tienda, así que conviene tener una forma de volver atrás si algo sale mal.
Una vez tenemos nuestro backup, podemos continuar.
Localizar la tabla de empleados
Entraremos en phpMyAdmin y seleccionaremos la base de datos correspondiente a nuestra instalación de PrestaShop.
Entre las tablas encontraremos la correspondiente a los empleados del Back Office.
Tradicionalmente, en muchas instalaciones la tabla se llama:
ps_employee
Pero no debemos asumir que el prefijo es ps_.
El prefijo se puede personalizar durante la instalación y, en PrestaShop 9, además, se genera de forma aleatoria por defecto. Por tanto, podemos encontrarnos con nombres diferentes. :contentReference[oaicite:1]{index=1}
ps_employee shop_employee prestashop_employee xxxxx_employee
Lo importante es localizar la tabla de empleados correspondiente a nuestra instalación.
El método antiguo: PrestaShop y cookie_key
Vamos ahora con el procedimiento que motivó originalmente este artículo.
En determinadas versiones antiguas de PrestaShop, la contraseña del empleado se almacenaba utilizando una combinación de la clave de la instalación y la contraseña, aplicando posteriormente MD5.
En esas instalaciones podíamos localizar la clave en:
/config/settings.inc.php
Dentro del archivo encontraríamos una definición similar a:
define('_COOKIE_KEY_', 'cadena_de_clave');
Lo que necesitábamos era únicamente el valor situado entre las comillas.
Ojo con esto
Si estás utilizando una versión moderna de PrestaShop y no encuentras settings.inc.php, no intentes crear el archivo ni seguir este procedimiento. La configuración y el sistema de autenticación han evolucionado.
Modificar la contraseña en una instalación antigua
Una vez localizada la tabla de empleados y obtenida la cookie_key, podíamos acudir a la pestaña SQL de phpMyAdmin.
La consulta utilizada en aquellas versiones era:
UPDATE ps_employee
SET passwd = MD5('cookie_keyNuevaContrasena')
WHERE email = 'elemailquevamosamodificar@prueba.com';
Debemos sustituir:
ps_employeepor el nombre real de nuestra tabla.cookie_keypor el valor real de la clave de la instalación.NuevaContrasenapor la nueva contraseña.elemailquevamosamodificar@prueba.compor el correo del empleado correspondiente.
Por ejemplo:
UPDATE ps_employee
SET passwd = MD5('MI_COOKIE_KEYMiNuevaContrasena')
WHERE email = 'admin@ejemplo.com';
Después de ejecutar la consulta, podíamos intentar acceder de nuevo al Back Office utilizando el correo electrónico y la nueva contraseña.
¿Por qué se utilizaba la cookie_key?
Este detalle tiene bastante importancia para entender qué estaba ocurriendo.
En aquellas versiones, la contraseña almacenada en la tabla employee no correspondía simplemente al texto que introducíamos en el formulario de acceso.
El sistema utilizaba la cookie_key de la instalación junto con la contraseña y almacenaba el resultado mediante MD5.
Por eso no bastaba con hacer:
UPDATE ps_employee
SET passwd = MD5('NuevaContrasena')
WHERE email = 'admin@ejemplo.com';
Había que reproducir el mecanismo utilizado por esa versión concreta de PrestaShop.
Pero las versiones modernas son otra historia
Y aquí es donde merece la pena actualizar el artículo original.
PrestaShop ha cambiado considerablemente desde aquellas primeras versiones. En PrestaShop 8, por ejemplo, el campo de contraseña del empleado ya se trata explícitamente como una contraseña hasheada, no como una contraseña almacenada mediante el antiguo mecanismo basado en MD5 y cookie_key. :contentReference[oaicite:2]{index=2}
Por tanto, una consulta como esta:
UPDATE ps_employee
SET passwd = MD5('...')
WHERE email = 'admin@ejemplo.com';
no debe utilizarse como procedimiento genérico para PrestaShop moderno.
El hecho de que sigamos encontrando la tabla employee no significa que podamos seguir modificando su columna passwd utilizando las reglas de una versión antigua.
¿Cómo hacerlo en PrestaShop moderno?
Si estamos trabajando con una instalación moderna, lo primero que haría sería utilizar el mecanismo normal de recuperación de contraseña del Back Office.
Si eso no es posible y tenemos acceso al servidor, hay una opción mucho más interesante en las versiones actuales que soportan el comando correspondiente: utilizar la CLI de PrestaShop.
En PrestaShop 9.2 se incorpora el comando:
php bin/console prestashop:employee:change-password
El comando permite seleccionar interactivamente el empleado y establecer una nueva contraseña.
También podemos proporcionar el correo electrónico y la contraseña directamente:
php bin/console prestashop:employee:change-password admin@ejemplo.com --password='NuevaContrasenaSegura'
La documentación oficial de PrestaShop indica que este comando está pensado precisamente para restablecer la contraseña de un empleado del Back Office. También dispone de una modalidad interactiva, que evita dejar la contraseña escrita directamente en el historial del shell. :contentReference[oaicite:3]{index=3}
Mucho mejor que tocar la base de datos
Si tu versión de PrestaShop dispone del comando prestashop:employee:change-password, es preferible utilizarlo antes que modificar directamente la columna passwd. Dejamos que PrestaShop se encargue de generar y almacenar la contraseña utilizando su propio sistema de autenticación.
¿Y si no tengo ese comando?
Entonces lo primero es identificar exactamente qué versión de PrestaShop estamos utilizando.
Esto es especialmente importante cuando estamos trabajando con una instalación antigua, una tienda migrada o un entorno local que lleva varios años funcionando.
Dependiendo de la versión, podemos encontrarnos con diferencias importantes en:
- La estructura de los archivos de configuración.
- El sistema utilizado para almacenar las contraseñas.
- El mecanismo de autenticación del Back Office.
- La forma recomendada de recuperar el acceso.
Por eso no recomiendo buscar una consulta SQL genérica por Internet y ejecutarla directamente contra cualquier PrestaShop.
PrestaShop 9: todavía más cambios
En PrestaShop 9 el Back Office ha dado otro paso importante hacia Symfony. El proceso de login y autorización del Back Office se ha migrado al sistema de seguridad de Symfony y ya no depende del antiguo mecanismo de autorización basado en Context::$cookie. :contentReference[oaicite:4]{index=4}
Esto es otra razón para no trasladar procedimientos antiguos directamente a instalaciones actuales.
Además, desde PrestaShop 9 el prefijo de las tablas se genera de forma aleatoria por defecto, aunque la estructura sigue incluyendo tablas como employee. :contentReference[oaicite:5]{index=5}
En otras palabras: la tabla puede seguir estando ahí, pero el procedimiento para modificar una contraseña ya no es necesariamente el mismo que utilizábamos hace años.
Un detalle importante sobre MD5
Hoy no utilizaría MD5 para almacenar una contraseña nueva.
El procedimiento original tiene sentido únicamente como referencia histórica para las versiones de PrestaShop que utilizaban ese mecanismo.
MD5 no es un algoritmo adecuado para almacenar contraseñas modernas. Los sistemas actuales utilizan funciones específicas de hashing de contraseñas, con mecanismos diseñados para hacer mucho más costoso el proceso de intentar recuperar una contraseña mediante fuerza bruta.
Por eso, si PrestaShop dispone de un mecanismo propio para cambiar la contraseña, lo correcto es dejar que sea PrestaShop quien genere el hash.
¿Qué procedimiento utilizaría?
Dependiendo de la versión, mi orden sería el siguiente:
- Intentar la recuperación normal de contraseña desde el Back Office.
- Si tenemos acceso al servidor, identificar la versión exacta de PrestaShop.
- En versiones que lo soporten, utilizar la CLI oficial para cambiar la contraseña.
- En instalaciones antiguas, aplicar el procedimiento específico de esa versión.
- Evitar modificar directamente
passwdsi no sabemos exactamente qué formato espera nuestra versión.
Antes de tocar MySQL
Identifica la versión de PrestaShop. Es probablemente el dato más importante de todo este procedimiento. Una consulta que funcionaba perfectamente hace años puede ser incorrecta para una instalación actual.
Conclusión
Cuando escribí originalmente este artículo, modificar directamente la tabla employee era una solución rápida para recuperar el acceso a determinadas instalaciones antiguas de PrestaShop.
Y ese procedimiento sigue teniendo interés, especialmente cuando nos encontramos con una tienda antigua funcionando en local y necesitamos recuperar el acceso sin disponer de las credenciales.
Pero PrestaShop ha cambiado bastante desde entonces.
En versiones antiguas podemos encontrarnos con el procedimiento basado en cookie_key y MD5:
UPDATE ps_employee
SET passwd = MD5('cookie_keyNuevaContrasena')
WHERE email = 'admin@ejemplo.com';
En versiones modernas, en cambio, debemos utilizar el mecanismo de autenticación correspondiente a nuestra versión y, cuando esté disponible, recurrir a la herramienta oficial de línea de comandos:
php bin/console prestashop:employee:change-password
La idea fundamental sigue siendo la misma: recuperar el acceso sin romper la instalación.
Lo que ha cambiado es la forma de hacerlo.
Y como siempre cuando vamos a meter mano directamente en la base de datos: backup antes de tocar absolutamente nada.
Visitas: 804
Automation & Data Specialist | Web Development | Data Processing & Integration
