Illustration de l'article sur la connexion sans mot de passe par magic link
Conversión y UX

Inicio de sesión sin contraseña (magic link) en PrestaShop en 2026: conversión checkout y fin del captcha

·sasha

La contraseña se ha vuelto un lastre para la conversión e-commerce

En las tiendas PrestaShop que instrumentamos, alrededor del 14 % de los visitantes identificados (ya clientes) abandonan en el momento del login. No antes — justo cuando deben introducir su contraseña. Y del 86 % que logra conectarse, el 28 % pasa por «contraseña olvidada», lo que añade un desvío de 2 a 4 minutos al recorrido de compra. Acumulado en una tienda mid-market, es entre el 8 y el 18 % de los ingresos que se pierde en la fricción de autenticación.

La contraseña arrastra también un coste oculto: del 30 al 50 % de los tickets de soporte e-commerce conciernen a una cuenta (restablecimiento, bloqueo tras intentos, cuenta no encontrada). A 5-8 € el ticket atendido, sobre 2 000 tickets al mes, son entre 35 y 80 K€/año de coste operativo. Sin contar el coste psicológico: un cliente expulsado del checkout por una contraseña olvidada se vuelve más difícil de reconquistar.

La alternativa existe desde hace tiempo y alcanza su madurez en 2026: el inicio de sesión sin contraseña mediante enlace mágico (magic link) o passkey (WebAuthn). El principio es idéntico al que ha permitido a Slack, Notion y Linear sustituir la contraseña por defecto: se envía un enlace único por email, el clic autentica. Sin contraseña que memorizar, sin captcha, sin bloqueo.

El flujo completo en cinco etapas:

  1. El usuario introduce su email en el formulario de inicio de sesión.
  2. El servidor genera un token criptográfico (típicamente 32 bytes aleatorios, codificados en base64url) con una vida útil limitada (15 minutos por defecto).
  3. El token se almacena en base de datos, vinculado al email, con un hash (nunca en claro) y una fecha de expiración.
  4. Se envía un email con un enlace de la forma https://tienda.es/login/magic?token=abc...
  5. Al hacer clic, el servidor valida el token, abre la sesión e invalida el token (uso único).

Cuatro propiedades criptográficas esenciales a respetar:

  • Token aleatorio criptográfico: generado con random_bytes() en PHP, nunca con mt_rand() o un UUID predecible.
  • Hash en base de datos: no se almacena el token en claro, se almacena su SHA-256 (como con una contraseña hasheada). Esto protege la base en caso de fuga.
  • Single-use: un token validado se invalida inmediatamente. Sin posibilidad de doble activación.
  • Time-bound: 15 minutos de expiración por defecto. Más allá, el token está muerto, el usuario pide otro enlace.

El módulo DfMagicLink para PrestaShop implementa estas cuatro garantías por defecto, además de una protección anti-enumeración (respuesta idéntica exista o no el email, para evitar revelar la base de clientes a un atacante) y un rate limiting por IP.

Magic link y passkey no son competidores sino complementarios, cada uno con su caso de uso:

  • Compatible con todos los terminales y todos los navegadores.
  • No requiere preinscripción: un email basta.
  • Depende de la entregabilidad del email (cf. email transaccional y DMARC/BIMI).
  • Fricción residual: abrir el buzón, hacer clic.

Passkey — biometría, instantáneo, vinculado al dispositivo

  • El usuario se autentica por biometría (Touch ID, Face ID, huella Android) o código PIN del dispositivo.
  • Ningún ida y vuelta por email, instantáneo.
  • Requiere una inscripción previa del passkey en cada dispositivo.
  • Estandarizado W3C WebAuthn, soportado por todos los navegadores modernos desde 2023.

El patrón híbrido 2026

El patrón que funciona hoy en e-commerce:

  • Primera conexión o nuevo terminal: magic link (universal, sin registro previo).
  • Tras la primera conexión exitosa, proponer registrar un passkey en el dispositivo para las conexiones siguientes («conéctese en un clic la próxima vez»).
  • Contraseña clásica opcional para los usuarios que la prefieran, o para la cuenta admin del back-office (donde el 2FA sigue siendo el rey).

Este patrón combina la universalidad del magic link y la instantaneidad del passkey, sin imponer un cambio brusco de hábito.

Impacto medido en la conversión

En las tiendas PrestaShop que han pasado de la contraseña clásica a un sistema magic link en primera línea:

  • Login successful rate: del 73 % al 94 % (ganancia: +21 puntos). El 6 % de fallos residuales son errores tipográficos de email o problemas de entregabilidad.
  • Tiempo medio de conexión: de 47 s a 22 s (clic en email incluido).
  • Tickets de soporte relacionados con la cuenta: −68 % de media en 3 meses.
  • Conversión checkout de los clientes identificados: +4 a +8 puntos.

En una tienda con 200 pedidos/mes a un carrito medio de 80 €, +6 puntos de conversión checkout sobre el 35 % de clientes identificados = +0,6 pedidos/día × 80 € = +1 460 €/mes de facturación. Más los tickets de soporte ahorrados. Más el coste psicológico de una experiencia fluida.

Implementación en PrestaShop: las elecciones de arquitectura

Arquitectura de la base de datos

Una tabla dedicada ps_df_magic_token con los campos:

  • id_token (PK auto-incremento)
  • id_customer (FK ps_customer, nullable para creación de cuenta al vuelo)
  • email (indexado)
  • token_hash (SHA-256, indexado para validación rápida)
  • expires_at (datetime)
  • consumed_at (datetime nullable, marcador de uso)
  • ip_request, ip_consume (auditoría forense)
  • user_agent (auditoría forense)

Un índice compuesto (token_hash, expires_at, consumed_at) para validar rápidamente un token entrante.

El controlador PrestaShop

Dos controladores modernos (Symfony) para PS 8/9:

  • MagicLinkRequestController — recibe el email, genera el token, envía el email. POST con rate limiting.
  • MagicLinkConsumeController — recibe el token vía GET, valida, abre la sesión vía $context->customer->logged = true y $context->cookie.

Atención a la trampa clásica: no abrir nunca la sesión en un GET sin verificación CSRF si el enlace se hace clic desde un email — un preview de enlace (Outlook, Gmail link preview) podría consumir el token. La solución: exigir un clic explícito en una página intermedia que POST el token, o detectar los preview agents (User-Agent con «GoogleImageProxy», «Mail-Preview») y no consumir el token a su paso.

La plantilla de email

El email magic link es un email transaccional de alta prioridad. Cuatro reglas:

  • Plazo de envío en menos de 5 segundos — más allá, el usuario vuelve a teclear su email.
  • Entregabilidad máxima — SPF, DKIM, DMARC alineados; sin imágenes con tracking que degraden la puntuación de spam; asunto corto («Conexión a tu tienda»).
  • Botón bien visible — no un enlace de hipertexto escondido en un párrafo. Un CTA dedicado de 200×50 px en color de marca.
  • Mención de seguridad — «si no es usted el origen de esta solicitud, ignore este mensaje» (atenúa el riesgo de ingeniería social).

La implementación limpia de la entregabilidad de email transaccional es un requisito previo: un magic link que acaba en spam es un cliente que abandona.

Seguridad: los ataques a anticipar

1. Enumeración de cuentas

Si la respuesta difiere según el email exista o no en base («le hemos enviado un enlace» vs «este email no existe»), un atacante puede enumerar la base de clientes por fuerza bruta. La regla: respuesta idéntica en ambos casos, y envío de email únicamente si la cuenta existe.

2. Phishing por enlace usurpado

Un atacante envía un email imitando su marca con un falso magic link que redirige a una página de phishing. La protección: sensibilizar a los clientes (mención en el email real: «verifique que la URL empieza realmente por tienda.es»), y publicar BIMI para mostrar el logo de la marca en Gmail/Yahoo. Es la palanca de confianza más eficaz en 2026.

3. Fuerza bruta sobre tokens

Con 32 bytes aleatorios, el espacio de búsqueda es 2256, prácticamente infranqueable. Pero un atacante podría intentar fuerza bruta sobre el endpoint de validación. La protección: rate limiting por IP (10 intentos/minuto máximo), y logging de los intentos inválidos.

4. Robo de sesión vía intercepción de email

Si el buzón del cliente se compromete, el atacante recibe los magic links. Es el riesgo residual principal del magic link: traslada la seguridad de la cuenta de la tienda hacia la seguridad del email. La protección: vida útil corta (15 min), invalidación en el login, y 2FA opcional para las cuentas con apuesta (carritos recurrentes, cuentas B2B).

5. Replay attack

Un atacante intercepta un magic link y lo reproduce. Protección: single-use forzado en base de datos (consumed_at no NULL bloquea la validación).

Casos particulares a tratar

Creación de cuenta en el primer login

Si el visitante introduce un email desconocido en base, dos opciones: rechazo («este email no tiene cuenta») o creación al vuelo. La creación al vuelo es UX-friendly (cero formulario de inscripción) pero exige un complemento posterior (nombre, dirección para la entrega) en el primer checkout. El patrón recomendado para PrestaShop: crear la cuenta al vuelo con un estado «incomplete», y completarla en el momento del checkout (que pide de todos modos dirección, teléfono, etc.).

Combinación potente: se envía al cliente un email de carrito abandonado que contiene tanto el resumen del carrito COMO un magic link para retomar la compra sin login. Conversión sobre carrito abandonado medida: ×1,6 vs un email clásico con login estándar. Es lo que combinan los módulos DfSaveCart y DfMagicLink cuando se despliegan juntos.

Cuenta B2B con multi-usuarios

Para las tiendas B2B con cuentas pro multi-usuarios, el magic link sigue siendo válido: cada colaborador recibe el enlace en su email pro. Pero se añade un audit log: quién se ha conectado cuándo, desde qué IP. Esto facilita los controles internos (quién ha pasado tal pedido, etc.).

Cuentas admin / back-office

Para el back-office PrestaShop, el magic link sigue siendo tentador pero el 2FA TOTP (Google Authenticator, Authy) o el passkey directo son preferibles. Un buzón comprometido que dé acceso al admin de tu tienda es game over. La regla: magic link en front-office, 2FA fuerte en back-office.

Compatibilidad PrestaShop 8 y 9

En PrestaShop 8 (Symfony 4) y 9 (Symfony 6), la implementación usa:

  • Rutas Symfony modernas vía config/routes.yml o atributos PHP 8.
  • Sesiones PrestaShop nativas vía $context->cookie + Customer::login().
  • Hooks para integrarse a los formularios de login nativos (displayCustomerLoginFormAfter).
  • Multilingüe vía XLIFF (FR, EN, ES, DE) para los emails y mensajes de error.
  • Multishop: tokens scopados por id_shop para no permitir la conexión cross-shop con un solo enlace.

El módulo DfMagicLink cubre estas compatibilidades nativamente y se integra con la sesión nativa PrestaShop sin forkear el sistema de auth.

FAQ

¿La contraseña debe desaparecer por completo?

No, e incluso es contraproducente. Algunos usuarios prefieren la contraseña por costumbre. El patrón recomendado: magic link en primera propuesta (95 % de los casos), contraseña en opción («usar una contraseña en su lugar»). Sin presión, sin fricción de aprendizaje.

No directamente, pero las trazas de auditoría (IP, user-agent, fechas) son datos personales sujetos al RGPD. Plazo de conservación recomendado: 1 año para los tokens consumidos (suficiente para auditoría forense), purga automática de los tokens expirados no consumidos. El derecho al olvido también debe suprimir estas trazas, salvo si son necesarias para una investigación en curso.

¿Qué pasa si el email del cliente está desactivado?

El magic link no se puede enviar, el cliente queda bloqueado. Para este caso, se mantiene un procedimiento de recuperación asistida: formulario de contacto, verificación de identidad por otros canales (número de teléfono, última compra), y luego cambio manual del email por el soporte. Es raro (1 % de los casos) pero debe estar documentado.

Sí, con deep links o universal links (iOS) / app links (Android). El enlace del email abre directamente la app si está instalada, con una sesión automática. PrestaShop no tiene app nativa, pero para las tiendas con PWA o app híbrida, esta integración es técnicamente estándar.

Con un módulo llave en mano como DfMagicLink, son típicamente 30 minutos de instalación + 1 a 2 horas de personalización (plantilla de email con los colores de la marca, mención de seguridad, traducción de las etiquetas). En desarrollo custom, calcular de 3 a 5 días para alcanzar la calidad de producción (seguridad, entregabilidad, tests).

En síntesis

El magic link no es un gadget UX — es la eliminación del freno más medible del checkout en 2026, con un impacto directo de +4 a +8 puntos de conversión sobre los clientes identificados y −60 % de tickets de soporte de cuenta. Combinado con los passkeys para los usuarios habituales, ofrece una experiencia de inicio de sesión que rivaliza por fin con Amazon, Google Pay y los líderes del mercado.

Para implementarlo limpiamente en PrestaShop, el módulo DfMagicLink cubre las cinco propiedades criptográficas esenciales (token aleatorio, hash en base, single-use, time-bound, anti-enumeración) y se integra con el sistema de sesión nativo PrestaShop. Para maximizar el ROI, se combina con el guardado de carrito por enlace mágico que aprovecha la misma infraestructura para la recuperación de carritos abandonados.

El requisito previo no negociable: una entregabilidad de email transaccional al nivel profesional (DMARC estricto, DKIM alineado, BIMI). Sin ello, el magic link acaba en spam y la tienda pierde más clientes de los que salva. Nuestra auditoría PrestaShop incluye sistemáticamente la verificación de esta capa email antes de recomendar un despliegue magic link.

Sigue leyendo

Artículos relacionados