Illustration de l'article sur la connexion sans mot de passe par magic link
Conversão e UX

Início de sessão sem palavra-passe (magic link) no PrestaShop em 2026: conversão no checkout e fim do captcha

·sasha

A palavra-passe tornou-se um lastro da conversão no e-commerce

Nas lojas PrestaShop que instrumentamos, cerca de 14 % dos visitantes identificados (já clientes) abandonam no momento do login. Não antes, no momento preciso em que têm de introduzir a palavra-passe. E dos 86 % que conseguem entrar, 28 % passam por « palavra-passe esquecida », o que acrescenta um desvio de 2 a 4 minutos ao percurso de compra. Acumulado numa loja de média dimensão, são 8 a 18 % de receita que se perde na fricção de autenticação.

A palavra-passe arrasta também um custo escondido: 30 a 50 % dos tickets de suporte no e-commerce dizem respeito a uma conta (reposição, bloqueio após tentativas, conta não encontrada). A 5 a 8 € por ticket tratado, em 2 000 tickets por mês, são 35 a 80 mil €/ano de custo operacional. Sem contar o custo psicológico: um cliente ejetado do checkout por uma palavra-passe esquecida torna-se mais difícil de reconquistar.

A alternativa existe há muito e atinge a maturidade em 2026: a autenticação sem palavra-passe por ligação mágica (magic link) ou passkey (WebAuthn). O princípio é o mesmo que permitiu ao Slack, ao Notion e ao Linear substituir a palavra-passe por defeito: envia-se uma ligação única por email, o clique autentica. Sem palavra-passe a memorizar, sem captcha, sem bloqueio.

O fluxo completo em cinco etapas:

  1. O utilizador introduz o seu email no formulário de login.
  2. O servidor gera um token criptográfico (tipicamente 32 octetos aleatórios, codificados em base64url) com uma duração de vida limitada (15 minutos por defeito).
  3. O token é guardado em base, ligado ao email, com um hash (nunca em claro) e uma data de expiração.
  4. Um email é enviado com uma ligação da forma https://loja.pt/login/magic?token=abc...
  5. Ao clique, o servidor valida o token, abre a sessão, e invalida o token (uso único).

Quatro propriedades criptográficas essenciais a respeitar:

  • Token aleatório criptográfico: gerado com random_bytes() em PHP, nunca com mt_rand() ou um UUID previsível.
  • Hash em base: não se guarda o token em claro, guarda-se o seu SHA-256 (como para uma palavra-passe). Isso protege a base em caso de fuga.
  • Single-use: um token validado é imediatamente invalidado. Sem dupla ativação possível.
  • Time-bound: 15 minutos de expiração por defeito. Depois disso, o token está morto, o utilizador pede nova ligação.

O módulo DfMagicLink para PrestaShop implementa estas quatro garantias por defeito, com além disso uma proteção anti-enumeração (resposta idêntica quer o email exista ou não, para não revelar a base de clientes a um atacante) e um rate limiting por IP.

Magic link e passkey não são concorrentes mas complementares, cada um com o seu caso de uso:

  • Compatível com todos os terminais e todos os navegadores.
  • Não exige nenhuma inscrição prévia: um email chega.
  • Depende da entregabilidade email (cf. email transacional e DMARC/BIMI).
  • Fricção residual: abrir a caixa de email, clicar.

Passkey: biometria, instantâneo, ligado ao aparelho

  • O utilizador autentica-se por biometria (Touch ID, Face ID, impressão digital Android) ou código PIN do aparelho.
  • Nenhuma ida e volta por email, instantâneo.
  • Exige um registo prévio do passkey em cada aparelho.
  • Standard W3C WebAuthn, suportado por todos os navegadores modernos desde 2023.

O padrão híbrido 2026

O padrão que funciona hoje no e-commerce:

  • Primeira ligação ou novo terminal: magic link (universal, sem registo prévio).
  • Após a primeira ligação bem-sucedida, propor registar um passkey no aparelho para as ligações seguintes (« entre com um clique da próxima vez »).
  • Palavra-passe clássica em opção para os utilizadores que a preferem, ou para a conta admin do back-office (onde o 2FA continua a mandar).

Este padrão combina a universalidade do magic link e a instantaneidade do passkey, sem impor uma mudança brutal de hábito.

Impacto medido na conversão

Nas lojas PrestaShop que passaram da palavra-passe clássica para um sistema magic link em primeira linha:

  • Login successful rate: de 73 % para 94 % (ganho: +21 pontos). Os 6 % de falhas residuais são gralhas no email ou problemas de entregabilidade.
  • Tempo médio de ligação: de 47 s para 22 s (clique no email incluído).
  • Tickets de suporte ligados à conta: −68 % em média em 3 meses.
  • Conversão checkout dos clientes identificados: +4 a +8 pontos.

Numa loja com 200 encomendas/mês e um carrinho médio de 80 €, +6 pontos de conversão checkout em 35 % de clientes identificados = +0,6 encomendas/dia × 80 € = +1 460 €/mês de faturação. Mais os tickets de suporte poupados. Mais o valor de uma experiência fluida.

Implementação no PrestaShop: as escolhas de arquitetura

Arquitetura da base de dados

Uma tabela dedicada ps_df_magic_token com os campos:

  • id_token (PK auto-increment)
  • id_customer (FK ps_customer, nullable para criação de conta na hora)
  • email (indexado)
  • token_hash (SHA-256, indexado para validação rápida)
  • expires_at (datetime)
  • consumed_at (datetime nullable, marcador de utilização)
  • ip_request, ip_consume (auditoria forense)
  • user_agent (auditoria forense)

Um índice compósito (token_hash, expires_at, consumed_at) para validar rapidamente um token à entrada.

O controlador PrestaShop

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

  • MagicLinkRequestController: recebe o email, gera o token, envia o email. POST com rate limiting.
  • MagicLinkConsumeController: recebe o token via GET, valida, abre a sessão via $context->customer->logged = true e $context->cookie.

Atenção à armadilha clássica: nunca abrir a sessão num GET sem verificação CSRF se a ligação é clicada a partir de um email: um preview de ligação (Outlook, Gmail link preview) poderia consumir o token. A solução: exigir um clique explícito numa página intermédia que faz POST do token, ou detetar os preview agents (User-Agent contendo « GoogleImageProxy », « Mail-Preview ») e não consumir o token à sua passagem.

O template de email

O email magic link é um email transacional de alta prioridade. Quatro regras:

  • Prazo de envio abaixo de 5 segundos: para lá disso, o utilizador recomeça a introduzir o email.
  • Entregabilidade máxima: SPF, DKIM, DMARC alinhados; sem imagens de rastreio que degradam o score de spam; assunto curto (« Início de sessão na sua loja »).
  • Botão bem visível: não uma ligação de texto escondida num parágrafo. Um CTA dedicado de 200×50 px na cor da marca.
  • Menção de segurança: « se não esteve na origem deste pedido, ignore esta mensagem » (atenua o risco de engenharia social).

A implementação limpa da entregabilidade do email transacional é um pré-requisito: um magic link que acaba no spam é um cliente que abandona.

Segurança: os ataques a antecipar

1. Enumeração de contas

Se a resposta difere consoante o email existe ou não em base (« enviámos-lhe uma ligação » vs « este email não existe »), um atacante pode enumerar a base de clientes por força bruta. A regra: resposta idêntica nos dois casos, e envio de email apenas se a conta existe.

2. Phishing por ligação usurpada

Um atacante envia um email a imitar a sua marca com um falso magic link que redireciona para uma página de phishing. A proteção: sensibilizar os clientes (menção no email real: « verifique que o URL começa por loja.pt »), e publicar BIMI para mostrar o logotipo da marca no Gmail/Yahoo. É a alavanca de confiança mais eficaz em 2026.

3. Força bruta de tokens

Com 32 octetos aleatórios, o espaço de pesquisa é 2256, praticamente intransponível. Mas um atacante poderia tentar força bruta no endpoint de validação. A proteção: rate limiting por IP (10 tentativas/minuto no máximo), e registo das tentativas inválidas.

4. Roubo de sessão por interceção de email

Se a caixa de email do cliente estiver comprometida, o atacante recebe os magic links. É o risco residual principal do magic link: desloca a segurança da conta da loja para a segurança do email. A proteção: duração de vida curta (15 min), invalidação no login, e 2FA opcional para as contas sensíveis (carrinhos recorrentes, contas B2B).

5. Replay attack

Um atacante interceta um magic link e reproduz o pedido. Proteção: single-use imposto em base (consumed_at não NULL bloqueia a validação).

Casos particulares a tratar

Criação de conta ao primeiro login

Se o visitante introduz um email desconhecido em base, duas opções: recusa (« este email não tem conta ») ou criação na hora. A criação na hora é UX-friendly (zero formulário de inscrição) mas pede um complemento posterior (nome, morada para a entrega) no primeiro checkout. O padrão recomendado para PrestaShop: criar a conta na hora com um estatuto « incomplete », e completá-la no momento do checkout (que pede de qualquer forma morada, telefone, etc.).

Combinação poderosa: envia-se ao cliente um email de carrinho abandonado que contém ao mesmo tempo o resumo do carrinho E um magic link para retomar a compra sem login. Conversão em carrinho abandonado medida: ×1,6 face a um email clássico com login standard. É o que combinam os módulos DfSaveCart e DfMagicLink quando implementados juntos.

Conta B2B com multiutilizadores

Para as lojas B2B com contas profissionais multiutilizadores, o magic link continua válido: cada colaborador recebe a ligação no seu email profissional. Mas acrescenta-se um registo de auditoria: quem entrou quando, de que IP. Isso facilita os controlos internos (quem fez determinada encomenda, etc.).

Contas admin / back-office

Para o back-office PrestaShop, o magic link é tentador mas o 2FA TOTP (Google Authenticator, Authy) ou o passkey direto são preferíveis. Uma caixa de email comprometida a dar acesso à administração da loja é game over. A regra: magic link no front-office, 2FA forte no back-office.

Compatibilidade PrestaShop 8 e 9

No PrestaShop 8 (Symfony 4) e 9 (Symfony 6), a implementação usa:

  • Rotas Symfony modernas via config/routes.yml ou atributos PHP 8.
  • Sessões PrestaShop nativas via $context->cookie + Customer::login().
  • Hooks para integração com os formulários de login nativos (displayCustomerLoginFormAfter).
  • Multilingue via XLIFF para os emails e mensagens de erro.
  • Multiloja: tokens delimitados por id_shop para não permitir a ligação cross-shop com uma única ligação.

O módulo DfMagicLink cobre estas compatibilidades nativamente e integra-se com a sessão nativa do PrestaShop sem forkar o sistema de autenticação.

FAQ

A palavra-passe deve desaparecer completamente?

Não, e seria até contraproducente. Alguns utilizadores preferem a palavra-passe por hábito. O padrão recomendado: magic link como primeira proposta (95 % dos casos), palavra-passe em opção (« usar antes uma palavra-passe »). Sem pressão, sem fricção de aprendizagem.

Não diretamente, mas os registos de auditoria (IP, user-agent, datas) são dados pessoais sujeitos ao RGPD. Duração de conservação recomendada: 1 ano para os tokens consumidos (suficiente para auditoria forense), purga automática dos tokens expirados não consumidos. O direito ao apagamento deve também eliminar estes registos, salvo se forem necessários a uma investigação em curso.

O que acontece se o email do cliente estiver desativado?

O magic link é inenviável, o cliente fica bloqueado. Para esse caso, mantém-se um procedimento de recuperação assistida: formulário de contacto, verificação de identidade por outros canais (número de telefone, última compra), e mudança de email manual pelo suporte. É raro (1 % dos casos) mas deve estar documentado.

Sim, com deep links ou universal links (iOS) / app links (Android). A ligação do email abre diretamente a app se estiver instalada, com sessão automática. O PrestaShop não tem app nativa, mas para as lojas com PWA ou app híbrida, esta integração é tecnicamente standard.

Com um módulo chave na mão como o DfMagicLink, são tipicamente 30 minutos de instalação + 1 a 2 horas de personalização (template de email nas cores da marca, menção de segurança, tradução dos textos). Em desenvolvimento à medida, conte 3 a 5 dias para atingir qualidade de produção (segurança, entregabilidade, testes).

Em síntese

O magic link não é um gadget de UX: é a remoção do travão mais mensurável do checkout em 2026, com um impacto direto de +4 a +8 pontos de conversão nos clientes identificados e −60 % de tickets de suporte de conta. Combinado com os passkeys para os utilizadores regulares, oferece uma experiência de ligação que rivaliza finalmente com a Amazon, o Google Pay e os líderes do mercado.

Para o implementar de forma limpa no PrestaShop, o módulo DfMagicLink cobre as cinco propriedades criptográficas essenciais (token aleatório, hash em base, single-use, time-bound, anti-enumeração) e integra-se com o sistema de sessão nativo do PrestaShop. Para maximizar o ROI, combina-se com a gravação de carrinho por ligação mágica que explora a mesma infraestrutura para a recuperação de carrinhos abandonados.

O pré-requisito não negociável: uma entregabilidade de email transacional a nível profissional (DMARC estrito, DKIM alinhado, BIMI). Sem isso, o magic link acaba no spam e a loja perde mais clientes do que salva. A nossa auditoria PrestaShop inclui sistematicamente a verificação desta camada de email antes de recomendar uma implementação de magic link.

Continuar a ler

Artigos relacionados