Contraseñas de clientes en PrestaShop: cómo se guardan y qué no hacer

Un cliente llama porque no recuerda su contraseña y te pide que se la digas. No puedes, y está bien que no puedas: la tienda no la sabe. Lo que PrestaShop guarda en la base de datos no es la contraseña, sino un resumen calculado a partir de ella del que no se puede volver atrás. Entender cómo funciona ese resumen te ahorra errores al migrar clientes, al importar cuentas y al dar soporte.

Qué guarda la tienda en realidad

Cuando un cliente crea su cuenta, PrestaShop pasa la contraseña por una función de hash: un cálculo que, a partir de un texto, produce una cadena de longitud fija. La misma contraseña da siempre un resultado comprobable, pero desde el resultado no se puede obtener la contraseña. Al iniciar sesión, la tienda vuelve a calcular el hash de lo que escribe el cliente y lo compara con el guardado. Si coinciden, entra.

El hash está en la columna passwd de la tabla de clientes (ps_customer con el prefijo habitual) y, para los empleados, en ps_employee. Que alguien vea esa columna no le da la contraseña, pero sí le permite probar contraseñas candidatas fuera de tu servidor, sin límite de intentos. Por eso importa mucho qué algoritmo se usa.

Cómo ha cambiado según la versión

PrestaShop 1.6 y anteriores

El hash era un MD5 de la contraseña concatenada con la clave de cookies de la instalación. MD5 es rapidísimo de calcular, y eso, que en otros contextos es una virtud, aquí es un defecto: un equipo corriente prueba enormes cantidades de candidatos por segundo. Si alguien obtiene la base de datos y la clave de cookies del fichero de configuración, las contraseñas débiles caen enseguida.

PrestaShop 1.7, 8 y 9

Desde 1.7 se usa bcrypt a través de las funciones de contraseñas de PHP. Bcrypt es lento a propósito y lleva una sal distinta por usuario, así que probar contraseñas es mucho más caro. La tienda sigue sabiendo comprobar los hashes antiguos: cuando un cliente con hash de 1.6 inicia sesión correctamente, PrestaShop lo recalcula con el algoritmo nuevo y lo guarda. Los clientes que no vuelven nunca conservan el hash viejo.

A partir de PrestaShop 8 tienes además una política de contraseñas configurable en los parámetros de seguridad de la tienda (longitud y nivel de fortaleza exigido), que se aplica a las contraseñas nuevas.

Migrar clientes desde otra plataforma

Al pasar de WooCommerce, Magento, Shopify u otro PrestaShop, la pregunta es siempre la misma: ¿podrán los clientes entrar con su contraseña? Depende del formato del hash de origen:

• Si el origen usa bcrypt estándar, el hash suele ser compatible y basta con copiarlo, siempre que lo pruebes antes con varias cuentas reales en la copia de pruebas.
• Si usa un formato propio (hashes con prefijos de la plataforma, varias rondas de otro algoritmo), PrestaShop no sabrá comprobarlo. Las opciones son un módulo puente que valide el formato antiguo en el primer inicio de sesión y lo convierta, o pedir a todos los clientes que restablezcan la contraseña.
• Si el origen no te da los hashes (algunas plataformas cerradas no los exportan), solo queda el restablecimiento.

Si vas a forzar el restablecimiento, prepáralo: un correo explicando el cambio de tienda, enviado por tandas desde un servidor de correo que no acabe en spam, y una página de recuperación que funcione en móvil. Muchos clientes llegarán desde el correo de un pedido y no desde ese aviso.

Restablecer contraseñas sin crear agujeros

El flujo correcto es el que trae PrestaShop: el cliente pide la recuperación, recibe un enlace con un código de un solo uso que caduca, y elige una contraseña nueva. Los errores aparecen cuando se intenta atajar:

• Poner tú una contraseña y dictársela por teléfono o enviarla por correo. Queda escrita en sitios que no controlas y el cliente rara vez la cambia.
• Usar una contraseña igual para todos en una importación («Tienda2024» para cada cliente migrado). Es la primera que probará cualquiera.
• Mandar las contraseñas en claro en el correo de bienvenida. Algunos módulos antiguos lo hacen. Revisa las plantillas de correo y quita esa variable.
• Pedir al cliente la contraseña para entrar en su cuenta y ver qué le pasa. Si necesitas ver lo que él ve, hay formas de hacerlo sin ella.

Qué no hacer nunca

1. Guardar contraseñas en claro o cifradas de forma reversible «por si acaso», en una tabla propia, en un CSV o en un campo de notas. Un módulo de un tercero que haga esto convierte cualquier fuga en un desastre.
2. Exportar la tabla de clientes completa para enviarla a una agencia o a un proveedor. Exporta solo las columnas que necesita y nunca passwd.
3. Dejar volcados de la base de datos en una carpeta pública del servidor. Un .sql en la raíz contiene todos los hashes y la clave para atacarlos.
4. Usar la misma clave de cookies en la copia de pruebas y en producción y dejar la copia accesible desde Internet sin contraseña.
5. Escribir en los registros de depuración el contenido de los formularios de acceso. Pasa más de lo que parece con módulos en modo depuración.

Si sospechas que se han filtrado

Si alguien ha tenido acceso a la base de datos, actúa como si los hashes estuvieran fuera:

• Cierra primero la vía de entrada: módulo vulnerable, credenciales de FTP o panel, volcado público.
• Cambia la contraseña de la base de datos y las de todos los empleados.
• Valora con un profesional si debes notificar la brecha a la autoridad de protección de datos y a los afectados. El RGPD exige evaluar el riesgo y, según el caso, notificar.
• Invita a los clientes a cambiar su contraseña, sobre todo si la reutilizan en otros servicios. Si el hash era de 1.6, la recomendación es más urgente.

Por qué actualizar también protege las contraseñas

Una tienda que sigue en 1.6 guarda las contraseñas de forma débil, y lo seguirá haciendo mientras no se migre. Además, las brechas que exponen la base de datos casi siempre llegan por módulos sin actualizar. Mantener PrestaShop, PHP y módulos al día no es solo cuestión de funciones nuevas: decide cuánto daño hace una fuga cuando ocurre.

Cómo resolverlo en PrestaShop

RKR Security Alert no gestiona contraseñas, pero vigila lo que suele venir antes de una fuga. Su auditoría avisa de copias de seguridad .sql o .zip accesibles en la raíz, de ficheros de configuración con permisos laxos que exponen las credenciales de la base de datos, del modo desarrollo y de display_errors activos en producción y de cuentas de administrador inactivas. Además detecta altas y cambios de empleados aunque se hagan por SQL directo, accesos al back-office desde IP nuevas y web shells en los ficheros, y te avisa por Telegram sin enviar ningún fichero fuera del servidor.