Autenticación de dos factores, políticas de contraseñas y seguridad del panel de administración en PrestaShop

El panel de administración de PrestaShop es la única puerta de tu tienda que abre todo lo demás: registros de clientes, historial de pedidos, configuración de pagos, el gestor de módulos capaz de ejecutar PHP arbitrario y un botón para exportar la base de datos a solo dos clics. Para la mayoría de atacantes es mucho más eficiente entrar por esa puerta con credenciales robadas que encontrar una vulnerabilidad en el código; y en muchísimas tiendas esa puerta se mantiene cerrada con una sola contraseña que el propietario también usa para su correo y para una cuenta de foro filtrada hace tres años. Esta guía trata de reforzar ese inicio de sesión: el segundo factor, las reglas de contraseña, las cuentas de empleados que hay detrás y la sesión que sigue abierta cuando te apartas de la pantalla. Es la capa de seguridad dedicada al control de acceso. Las demás capas — permisos de archivos, cabeceras, parches, filtrado de bots — están en la lista completa de endurecimiento de seguridad, y la visión general más tranquila y no técnica está en la guía en lenguaje claro para propietarios de tiendas.

Revisado en junio de 2026 frente al comportamiento del panel de administración de PrestaShop 1.6, 1.7, 8 y 9, y las directrices actuales de NIST sobre contraseñas.

Por dónde se filtran realmente los accesos de administración

Antes de buscar herramientas, conviene poner nombre a los fallos concretos, porque cada uno tiene una solución distinta y específica para PrestaShop:

• Reutilización de credenciales. La brecha más común no tiene nada que ver con el código de PrestaShop. Una contraseña de administrador filtrada desde un servicio sin relación se prueba contra tu página AdminLogin mediante una herramienta automatizada. La contraseña nunca fue "descifrada": simplemente apareció en una filtración.
• Cuentas compartidas. Un único acceso admin@ usado por tres personas hace que el registro de actividad atribuya todos los cambios a la misma fila, y no puedes revocar el acceso de una persona sin dejar fuera a las demás.
• Personal con permisos excesivos. Un empleado de preparación de pedidos con permisos de SuperAdmin es un agujero del tamaño de un SuperAdmin si su portátil cae en un phishing; para empezar, no tenía ningún motivo para llegar al gestor de módulos.
• Sin segundo factor. Una contraseña por sí sola es un punto único de fallo. Basta con phishing, un keylogger o una credencial reutilizada.
• Sesiones que nunca terminan. Un panel de administración abierto en un equipo compartido o robado es una sesión autenticada que cualquiera puede manejar.

Todo lo que sigue asigna una solución a cada uno de esos problemas. Nada requiere tocar archivos del núcleo.

Autenticación de dos factores en el panel de administración de PrestaShop

La autenticación de dos factores divide el inicio de sesión entre algo que sabes (la contraseña) y algo que tienes (un código de tu teléfono). Si roban una parte, aún no pueden superar la otra. En PrestaShop, la vía habitual para añadir 2FA al panel de administración es un módulo de seguridad fiable o una capa externa de control de acceso delante del inicio de sesión; por eso lo primero que debes decidir es cómo vas a añadirla, no solo dónde hacer clic.

Cómo se añade realmente la 2FA al panel de administración

No des por hecho que el núcleo incluye un interruptor de autenticación de dos factores listo para tu versión. En general, PrestaShop 1.6, 1.7 y 8 necesitan un módulo externo fiable o una capa externa de control de acceso para poner un segundo factor en el panel de administración. Trata la 2FA como "nativa" únicamente cuando lo hayas verificado para tu versión exacta en la documentación oficial de esa versión: que una función exista en una versión menor no demuestra que exista en la que estás usando.

Las opciones prácticas, ordenadas aproximadamente por esfuerzo, son:

• Un módulo fiable de seguridad para administración que añada TOTP (el código rotatorio de seis dígitos de una aplicación de autenticación como Google Authenticator, Authy, Microsoft Authenticator, 1Password o KeePass con un plugin TOTP). Es la vía más habitual y la única que ofrece un verdadero segundo factor por empleado basado en una aplicación.
• Una capa externa de control de acceso: un proxy de SSO/identidad o un WAF/proxy inverso que pida un segundo factor antes de que la petición llegue siquiera a PrestaShop. Protege la superficie de inicio de sesión sin tocar el núcleo en absoluto.
• Lista de IP permitidas (más abajo) como control compensatorio cuando no puedes desplegar ninguna de las opciones anteriores; no es un segundo factor real, pero reduce drásticamente la superficie de ataque.

Cómo activarla

Sea cual sea la vía que elijas, los pasos de configuración están en el propio módulo o proxy, no en una pantalla fija del núcleo; por tanto, sigue las instrucciones de la herramienta concreta que despliegues. Para un factor basado en una aplicación de autenticación (TOTP), el flujo suele ser:

• Activa el segundo factor para tu propia cuenta en la configuración del módulo o del proxy.
• Escanea el código QR con tu aplicación de autenticación y luego introduce el código actual para demostrar que el reloj está sincronizado. Una herramienta bien construida no finalizará la configuración hasta que confirmes ese código, de modo que no puedas quedarte fuera por haber escaneado mal el secreto.
• Guarda y después pruébalo: cierra sesión y vuelve a entrar. Debería pedirte el código rotatorio después de la contraseña.

Dos notas operativas que evitan problemas reales. Primero, TOTP depende de que los relojes del teléfono y del servidor coincidan dentro de una pequeña ventana; si se rechazan los códigos, comprueba que la hora del servidor sea correcta (NTP) antes de asumir que la función está rota. Segundo, si tu módulo o proxy de 2FA ofrece códigos de recuperación o respaldo, guárdalos fuera del teléfono: en una entrada del gestor de contraseñas, no en una nota adhesiva. Si no los ofrece, documenta de antemano su propio procedimiento de recuperación, porque un teléfono perdido o borrado sin alternativa puede exigir una intervención a nivel de base de datos (limpiar las columnas 2FA relevantes, a menudo en tu fila ps_employee) para recuperar el acceso.

Hazla obligatoria, no opcional

Un solo empleado sin 2FA es el eslabón débil del que cuelga toda la cadena: un atacante que entre en cualquier cuenta ya tiene un punto de apoyo para escalar. La herramienta que uses normalmente activa el segundo factor por persona en lugar de imponerlo en toda la cuenta, así que "obligatoria" es una política que aplicas comprobando que todos los empleados activos la tengan habilitada. Si tienes varios empleados y quieres que el registro sea forzoso (el personal nuevo no puede operar hasta configurarlo), busca un módulo o una capa de control de acceso que admita registro obligatorio. En 1.6 y primeras 1.7 especialmente, un módulo o una capa externa es la vía, salvo que bloquees el acceso por IP.

Una política de contraseñas alineada con las recomendaciones actuales

El objetivo no son contraseñas "complejas", sino contraseñas que no puedan adivinarse, reutilizarse ni probarse en masa. Las recomendaciones modernas (NIST y otras) han dejado atrás el viejo teatro de complejidad y rotación para centrarse en longitud y unicidad.

La instrucción práctica para el personal es breve: cada cuenta del panel de administración usa una contraseña única, generada aleatoriamente y guardada en un gestor (Bitwarden, 1Password, KeePass). Una cadena aleatoria de 20 caracteres es más fuerte y más fácil de llevar que una contraseña "ingeniosa" y memorable, porque nadie tiene que escribirla ni recordarla. Cómo almacena PrestaShop esa contraseña depende de tu versión: las versiones modernas usan un algoritmo sólido de hashing de contraseñas (el hashing con factor de coste detrás de PrestaShop\PrestaShop\Core\Crypto\Hashing), por lo que una filtración de la base de datos no entrega el texto plano; pero la antigua 1.6 usaba un esquema más débil basado en la clave de cookie. Si sigues en 1.6, trata sus hashes almacenados como una protección de bajo valor: planifica una actualización o migración para que las contraseñas se vuelvan a hashear con el algoritmo moderno y, mientras tanto, apóyate con fuerza en contraseñas únicas y robustas. En cualquier caso, el hashing no sirve de nada si la contraseña era admin123 y vive en una lista pública de palabras.

Un control específico de PrestaShop que conviene conocer: el flujo de restablecimiento de contraseña está limitado por el valor de configuración PS_PASSWD_TIME_BACK (minutos entre solicitudes de restablecimiento del panel de administración), así que un atacante no puede inundar el correo con mensajes de recuperación. Rara vez necesitas tocarlo, pero existe.

Cuentas de empleados: una persona, un acceso, privilegio mínimo

Este es el fallo que socava en silencio todos los demás controles. El modelo de permisos de PrestaShop es realmente capaz; el problema casi siempre es que se deja demasiado abierto.

Una cuenta por persona

Cada persona debe tener su propio registro de empleado en Advanced Parameters → Team → Employees. Esto te da tres cosas a la vez: una pista de auditoría que identifica quién hizo qué (PrestaShop registra las acciones contra el empleado que actúa), la posibilidad de desactivar a alguien que se va sin cambiar la contraseña de nadie más y 2FA por persona. Los accesos compartidos renuncian a las tres.

Perfiles y principio de privilegio mínimo

En PrestaShop, los permisos no se asignan por empleado: se asignan a un Profile (en Advanced Parameters → Team → Permissions), y cada empleado recibe un perfil. Crea perfiles que coincidan con funciones reales y la cuadrícula View / Add / Edit / Delete hará el resto:

Las dos reglas que importan: reduce el perfil SuperAdmin al propietario y, como mucho, a un responsable técnico de máxima confianza; y recuerda que el permiso Modules equivale en la práctica a derechos de ejecución de código: cualquiera que pueda instalar un módulo puede ejecutar PHP en tu servidor, así que trátalo como el permiso crítico que es, no como una comodidad para repartir.

Bloquear la propia superficie de inicio de sesión

Los dos factores protegen las credenciales; estos controles protegen la puerta que abren.

Mantén aleatorio el nombre de la carpeta de administración

PrestaShop instala el panel de administración en un directorio aleatorio (algo como /admin47ab9c/) precisamente para que los bots no puedan encontrarlo adivinando /admin o /backoffice. Déjalo aleatorio. Si durante una migración se renombró a algo predecible, cambia el nombre de la carpeta en disco y PrestaShop detectará automáticamente la nueva ruta. La ocultación no es un control de seguridad por sí sola, pero te saca del torrente de escaneos automatizados que machacan las rutas obvias.

Limita y vigila los inicios de sesión fallidos

Las herramientas de fuerza bruta y relleno de credenciales dependen de poder probar miles de combinaciones rápidamente. Hay dos defensas aplicables: en el borde de la aplicación, pon un desafío en el formulario de inicio de sesión para que las herramientas automatizadas se atasquen; está cubierto en reCAPTCHA para PrestaShop. En el borde de red, restringe quién puede llegar siquiera al inicio de sesión. Si tu equipo entra desde una IP fija de oficina o una VPN, una lista de permitidos en .htaccess o en el firewall sobre el directorio de administración bloquea cualquier otro origen, aunque tenga una contraseña válida; esa regla y las demás reglas de servidor están en reglas de seguridad y rendimiento de .htaccess para PrestaShop. En cualquier caso, revisa el patrón de intentos fallidos: una ráfaga de fallos desde una IP contra un empleado es un ataque en curso.

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

La pantalla de intentos bloqueados de Total Defender enumera las entradas por tipo, motivo, dirección IP y fecha e indica que no hubo intentos bloqueados en las últimas 24 horas.

Seguridad de sesión: la parte que todos olvidan

Puedes hacer todo lo anterior y aun así entregar a un atacante una sesión autenticada si el panel de administración queda abierto e iniciado en una máquina desatendida. Tres controles cierran esa brecha:

• Tiempo de espera por inactividad. PrestaShop caduca las sesiones del panel de administración según el ajuste PS_COOKIE_LIFETIME_BO (la duración de la cookie de administración). Mantenlo lo bastante estricto para que una pantalla abandonada cierre sesión sola: corto para puestos compartidos, más largo solo cuando la máquina sea realmente privada.
• Administración solo por HTTPS. El panel de administración debe servirse por HTTPS para que la cookie de sesión no pueda capturarse en una red de cafetería u hotel. Si tu tienda todavía no está completamente en HTTPS, corrige eso primero; la guía está en configurar SSL y HTTPS en PrestaShop.
• Cookies Secure y HttpOnly. Una vez que todo el sitio usa HTTPS, la cookie de sesión de administración debe llevar las marcas Secure y HttpOnly, para que nunca se envíe en texto claro y JavaScript no pueda leerla. Una cookie robada evita la 2FA, así que esto no es opcional.

Puedes verificar la duración actual de la cookie del panel de administración directamente desde la base de datos; el valor se almacena en días:

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

Supervisa el panel de administración, no solo la tienda visible

PrestaShop registra algunos eventos y errores del panel de administración, y ese registro es una señal útil de alerta temprana; pero trátalo como un registro parcial, no como una pista de auditoría completa ni como un SIEM. El registro interno puede mostrar cosas como una nueva cuenta de empleado que no has creado, un cambio repentino de permisos o una edición inesperada de la configuración de pagos. Por sí solo, no ofrece una supervisión fiable de inicios de sesión por IP o por país: detectar "un inicio de sesión a las 04:00 desde un país en el que no operas" suele requerir correlacionar registros de acceso del servidor, un módulo de seguridad dedicado o los registros de tu WAF/proxy inverso, donde se guarda la IP de origen. Acostúmbrate a revisar el registro interno, como mínimo cada mes y semanalmente si tienes rotación de personal, y combínalo con el registro de servidor que te dé la fuente de autenticación. Si ya sospechas que has pasado de la fase de alerta a una intrusión activa, deja de leer consejos de endurecimiento y sigue el plan de respuesta a incidentes en respuesta ante una brecha de datos: qué hacer si hackean tu tienda.

Si no puedes desplegar un módulo de 2FA

Muchas tiendas están atrapadas en una configuración congelada: una versión antigua mantenida por un tema heredado, un módulo heredado o una versión de PHP que una actualización rompería, donde añadir un módulo de seguridad resulta incómodo. No te quedas sin opciones: un módulo fiable puede añadir el segundo factor cuando encaja, una capa externa de control de acceso puede colocarse delante del inicio de sesión, una lista de IP permitidas puede cercar el panel de administración y el resto de consejos de control de acceso de esta guía se aplican igual. La estrategia más amplia para endurecer una tienda que de verdad aún no puedes mover — parches virtuales y controles compensatorios — tiene su propio artículo en endurecimiento avanzado de PrestaShop para tiendas que todavía no puedes actualizar.

Bloqueo del panel de administración en 10 minutos, en orden

• Activa ahora la 2FA en tu propia cuenta SuperAdmin mediante tu módulo de seguridad o capa de control de acceso, y confirma que hay una opción de recuperación guardada fuera del dispositivo.
• Lista todos los empleados activos. Deshabilita los accesos compartidos; da a cada persona su propia cuenta.
• Abre Permissions y rebaja a cualquiera que no necesite SuperAdmin. Verifica que solo lo tengan 1-2 personas y que el acceso a Modules esté muy restringido.
• Acompaña a cada persona restante para activar su propia 2FA.
• Confirma que cada contraseña de administración sea única y generada por un gestor; rota las que no lo sean.
• Comprueba que el nombre de la carpeta de administración siga siendo aleatorio, no /admin.
• Ajusta la duración de la cookie del panel de administración para que las sesiones inactivas se cierren.
• Confirma que la administración sea solo HTTPS y que la cookie de sesión sea Secure + HttpOnly.
• Lee un mes de registros de administración. Toma nota de cómo se ve lo "normal" para que lo anormal destaque la próxima vez.

Preguntas frecuentes

¿PrestaShop incluye autenticación de dos factores integrada para el panel de administración?

No lo des por hecho para tu versión. PrestaShop 1.6, 1.7 y 8 suelen necesitar un módulo fiable de seguridad para administración o una capa externa de control de acceso (un proxy de SSO/identidad o un WAF delante del inicio de sesión) para añadir un segundo factor al panel de administración. Trata la 2FA como nativa únicamente cuando lo hayas verificado en la documentación oficial de tu versión exacta: una función en una versión menor no demuestra que exista en la que estás usando.

¿Qué pasa si pierdo el teléfono con mi aplicación de autenticación?

Si tu herramienta de 2FA ofrece códigos de recuperación o respaldo, los guardas fuera del teléfono (en una entrada del gestor de contraseñas) y usas uno para volver a entrar. Si no los ofrece, recurres a su procedimiento de recuperación documentado, que en muchas configuraciones implica una intervención a nivel de base de datos: limpiar las columnas 2FA relevantes en tu fila ps_employee para desactivar el segundo factor de esa cuenta, de modo que puedas iniciar sesión y registrarla de nuevo. Por eso defines la vía de recuperación antes de activar la 2FA, no después.

¿Debo obligar a que mis contraseñas de administración caduquen cada 90 días?

No. Las recomendaciones actuales (NIST y otras) abandonaron la rotación programada porque empuja a la gente de Summer2024! → Summer2025!, que es más débil, no más fuerte. Cambia una contraseña solo ante sospecha de compromiso. Pon el esfuerzo en la longitud y la unicidad: una cadena de 16+ caracteres, generada aleatoriamente, nunca reutilizada y creada por un gestor de contraseñas, una por cuenta.

¿De verdad merece la pena renombrar la carpeta de administración?

Merece la pena mantenerla aleatoria, no obsesionarse con ella. PrestaShop ya instala el panel de administración en un directorio aleatorio para que los bots no puedan encontrarlo adivinando /admin o /backoffice; si una migración dejó el tuyo con un nombre predecible, renombra la carpeta en disco y PrestaShop detectará la nueva ruta. Es ocultación, no un control de seguridad: te saca del torrente de escaneos automatizados, pero solo se gana el sitio junto a 2FA, contraseñas robustas y limitación de intentos de acceso.

¿Cómo detengo los ataques de fuerza bruta y relleno de credenciales contra el inicio de sesión?

Aplica dos capas en los bordes. En el borde de la aplicación, pon un desafío en el formulario de inicio de sesión (reCAPTCHA) para que las herramientas automatizadas se atasquen. En el borde de red, restringe quién puede llegar al inicio de sesión: si tu equipo entra desde una IP fija de oficina o una VPN, una lista de permitidos en .htaccess o en el firewall sobre el directorio de administración rechaza cualquier otro origen, contraseña válida o no. Nada de eso sustituye a la 2FA, que es lo que te salva cuando se filtra una contraseña real.

Entonces, ¿qué ganas realmente con esto?

Ejecuta la lista y la economía de atacar tu tienda cambia. El relleno de credenciales falla en el segundo factor. Una contraseña obtenida por phishing no sirve sin el teléfono. Una cuenta comprometida de un empleado de preparación de pedidos no puede llegar al gestor de módulos. Un portátil abandonado cierra la sesión por sí solo. Nada exige un desarrollador, una edición del núcleo ni una actualización que no puedas permitirte: es configuración del panel de administración y un gestor de contraseñas. Creamos módulos de seguridad y gestionamos tiendas nosotros mismos, así que el planteamiento honesto es este: el panel de administración es donde una brecha pasa de incómoda a catastrófica, y el control de acceso es la hora más barata y de mayor impacto que puedes dedicarle. Cuando estés listo para endurecer las capas por debajo del inicio de sesión — archivos, cabeceras, parches, tráfico de bots — la lista completa de endurecimiento es el mapa para el resto.