Palavras-passe dos clientes no PrestaShop: como são guardadas e o que não fazer

Um cliente telefona porque não se lembra da palavra-passe e pede-lhe que lha diga. Não pode, e ainda bem: a loja não a conhece. O que o PrestaShop guarda na base de dados não é a palavra-passe, mas um resumo calculado a partir dela, do qual não é possível voltar atrás. Perceber como funciona esse resumo poupa-lhe erros ao migrar clientes, ao importar contas e ao dar suporte.

O que a loja guarda realmente

Quando um cliente cria a sua conta, o PrestaShop passa a palavra-passe por uma função de hash: um cálculo que, a partir de um texto, produz uma cadeia de comprimento fixo. A mesma palavra-passe dá sempre um resultado verificável, mas a partir do resultado não se consegue obter a palavra-passe. No início de sessão, a loja volta a calcular o hash do que o cliente escreve e compara-o com o guardado. Se coincidirem, entra.

O hash está na coluna passwd da tabela de clientes (ps_customer com o prefixo habitual) e, para os funcionários, em ps_employee. Quem vê essa coluna não fica com a palavra-passe, mas pode testar palavras-passe candidatas fora do seu servidor, sem limite de tentativas. Por isso importa muito o algoritmo usado.

Como mudou consoante a versão

PrestaShop 1.6 e anteriores

O hash era um MD5 da palavra-passe concatenada com a chave de cookies da instalação. O MD5 calcula-se rapidíssimo e isso, que noutros contextos é uma virtude, aqui é um defeito: um computador vulgar testa enormes quantidades de candidatos por segundo. Se alguém obtiver a base de dados e a chave de cookies do ficheiro de configuração, as palavras-passe fracas caem logo.

PrestaShop 1.7, 8 e 9

Desde a 1.7 usa-se bcrypt através das funções de palavras-passe do PHP. O bcrypt é lento de propósito e usa um sal diferente por utilizador, por isso testar palavras-passe sai muito mais caro. A loja continua a saber verificar os hashes antigos: quando um cliente com hash da 1.6 inicia sessão corretamente, o PrestaShop recalcula-o com o algoritmo novo e guarda-o. Os clientes que nunca voltam mantêm o hash antigo.

A partir do PrestaShop 8 tem ainda uma política de palavras-passe configurável nos parâmetros de segurança da loja (comprimento e nível de robustez exigido), que se aplica às palavras-passe novas.

Migrar clientes a partir de outra plataforma

Ao passar de WooCommerce, Magento, Shopify ou outro PrestaShop, a pergunta é sempre a mesma: os clientes vão conseguir entrar com a sua palavra-passe? Depende do formato do hash de origem:

• Se a origem usa bcrypt padrão, o hash costuma ser compatível e basta copiá-lo, desde que o teste antes com várias contas reais na cópia de testes.
• Se usa um formato próprio (hashes com prefixos da plataforma, várias rondas de outro algoritmo), o PrestaShop não o saberá verificar. As opções são um módulo ponte que valide o formato antigo no primeiro início de sessão e o converta, ou pedir a todos os clientes que redefinam a palavra-passe.
• Se a origem não lhe fornece os hashes (algumas plataformas fechadas não os exportam), só resta a redefinição.

Se vai forçar a redefinição, prepare-a: um e-mail a explicar a mudança de loja, enviado por lotes a partir de um servidor de correio que não acabe no spam, e uma página de recuperação que funcione no telemóvel. Muitos clientes vão chegar pelo e-mail de uma encomenda e não por esse aviso.

Redefinir palavras-passe sem abrir brechas

O fluxo correto é o que o PrestaShop traz: o cliente pede a recuperação, recebe uma ligação com um código de utilização única que expira e escolhe uma palavra-passe nova. Os erros aparecem quando se tenta encurtar caminho:

• Definir você uma palavra-passe e ditá-la por telefone ou enviá-la por e-mail. Fica escrita em sítios que não controla e o cliente raramente a altera.
• Usar a mesma palavra-passe para todos numa importação («Loja2024» para cada cliente migrado). É a primeira que qualquer pessoa vai experimentar.
• Enviar as palavras-passe em claro no e-mail de boas-vindas. Alguns módulos antigos fazem-no. Reveja os modelos de e-mail e retire essa variável.
• Pedir ao cliente a palavra-passe para entrar na conta dele e ver o que se passa. Se precisa de ver o que ele vê, há formas de o fazer sem ela.

O que nunca fazer

1. Guardar palavras-passe em claro ou cifradas de forma reversível «por precaução», numa tabela própria, num CSV ou num campo de notas. Um módulo de terceiros que faça isto transforma qualquer fuga num desastre.
2. Exportar a tabela de clientes completa para a enviar a uma agência ou a um fornecedor. Exporte apenas as colunas necessárias e nunca passwd.
3. Deixar cópias da base de dados numa pasta pública do servidor. Um .sql na raiz contém todos os hashes e a chave para os atacar.
4. Usar a mesma chave de cookies na cópia de testes e em produção e deixar a cópia acessível pela Internet sem palavra-passe.
5. Escrever nos registos de depuração o conteúdo dos formulários de acesso. Acontece mais do que parece com módulos em modo de depuração.

Se suspeita de uma fuga

Se alguém teve acesso à base de dados, aja como se os hashes já estivessem cá fora:

• Feche primeiro a via de entrada: módulo vulnerável, credenciais de FTP ou do painel, cópia pública.
• Altere a palavra-passe da base de dados e as de todos os funcionários.
• Avalie com um profissional se deve notificar a violação à autoridade de proteção de dados e aos afetados. O RGPD exige avaliar o risco e, consoante o caso, notificar.
• Convide os clientes a alterar a palavra-passe, sobretudo se a reutilizam noutros serviços. Se o hash era da 1.6, a recomendação é mais urgente.

Porque atualizar também protege as palavras-passe

Uma loja que continua na 1.6 guarda as palavras-passe de forma fraca, e vai continuar a fazê-lo enquanto não for migrada. Além disso, as violações que expõem a base de dados chegam quase sempre por módulos desatualizados. Manter o PrestaShop, o PHP e os módulos em dia não é só uma questão de funcionalidades novas: decide quanto dano faz uma fuga quando acontece.

Como resolver no PrestaShop

O RKR Security Alert não gere palavras-passe, mas vigia o que costuma vir antes de uma fuga. A sua auditoria avisa de cópias de segurança .sql ou .zip acessíveis na raiz, de ficheiros de configuração com permissões demasiado abertas que expõem as credenciais da base de dados, do modo de desenvolvimento e do display_errors ativos em produção e de contas de administrador inativas. Deteta ainda criações e alterações de funcionários mesmo que sejam feitas por SQL direto, acessos ao back office a partir de IP novos e web shells nos ficheiros, e avisa-o por Telegram sem enviar nenhum ficheiro para fora do servidor.