Chaves de segurança do WordPress: quando e como trocar

As chaves de segurança do WordPress ajudam a assinar cookies de autenticação e outros dados usados pelo sistema. Quando você substitui essas chaves no arquivo wp-config.php, os cookies existentes deixam de ser válidos. Na prática, os usuários conectados precisam entrar novamente no painel.

Essa troca é útil quando existe suspeita de acesso indevido, exposição do arquivo de configuração, compartilhamento inseguro de credenciais ou necessidade de encerrar sessões que você não consegue identificar. Ela também pode fazer parte da resposta a um incidente. Porém, não corrige sozinha uma invasão e não substitui a remoção da causa do problema.

Este guia mostra como renovar as chaves com cuidado, validar o resultado e recuperar o site caso a edição gere um erro.

O que muda quando você troca as chaves do WordPress

Uma instalação comum possui oito constantes relacionadas a autenticação no wp-config.php. Elas incluem chaves como AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY e NONCE_KEY, além das constantes correspondentes terminadas em SALT.

Esses valores devem ser longos, aleatórios e diferentes entre si. Eles não são senhas para entrar no painel. O WordPress usa essas sequências como parte dos mecanismos que verificam cookies e requisições.

Depois da substituição, espere os seguintes efeitos:

• usuários conectados serão solicitados a entrar novamente;
• cookies antigos de autenticação deixarão de ser aceitos;
• formulários administrativos abertos antes da mudança podem apresentar aviso de sessão expirada;
• ações protegidas por nonces antigos podem precisar ser repetidas;
• sessões abertas em celulares e outros navegadores também podem perder a autenticação.

A troca não apaga contas, posts, páginas ou pedidos. Ela também não redefine as senhas cadastradas no WordPress.

Quando vale a pena renovar chaves e salts

Não é necessário alterar as chaves toda semana sem motivo. A mudança provoca desconexões e pode interromper o trabalho de editores, atendentes e administradores.

Considere a renovação nestas situações:

1. O arquivo wp-config.php foi exposto. Isso pode acontecer por um backup público, configuração incorreta do servidor ou envio do arquivo por um canal inadequado.
2. Um administrador desconhecido apareceu no site. Antes da troca, preserve registros e identifique como a conta foi criada.
3. Uma credencial de hospedagem ou SFTP foi compartilhada indevidamente. Quem teve acesso aos arquivos pode ter lido as chaves.
4. Um prestador com acesso ao servidor saiu do projeto. Revogue também as contas de painel, SSH, SFTP e provedor de nuvem.
5. O site foi restaurado depois de um incidente. A rotação ajuda a invalidar cookies criados com os valores anteriores.
6. Há sessões suspeitas após a troca de senhas. Trocar apenas a senha de um usuário não substitui uma revisão completa dos acessos.

Em caso de invasão confirmada, preserve uma cópia para análise antes de sobrescrever arquivos e registros. Uma alteração precipitada pode eliminar pistas úteis.

Pré requisitos antes de editar o wp-config.php

A edição é curta, mas um caractere fora do lugar pode causar erro no site. Prepare uma forma de recuperação antes de começar.

Você vai precisar de:

• acesso ao servidor por painel, SFTP ou SSH;
• permissão para editar o wp-config.php;
• cópia do arquivo atual armazenada fora da pasta pública;
• uma janela de manutenção com a equipe avisada;
• uma conta administrativa válida para testar o novo login;
• acesso alternativo ao servidor caso o painel do WordPress fique indisponível.

Faça um backup antes de alterar o WordPress. Para este procedimento, a cópia do wp-config.php é essencial. Se houver suspeita de incidente, também preserve arquivos, banco de dados e registros do servidor.

Em uma VPS na LetsCloud, identifique primeiro onde a instalação está armazenada e qual usuário tem permissão sobre o arquivo. Verifique no painel da sua instância se existe uma opção adequada de snapshot para o seu cenário. Mesmo quando houver snapshot, mantenha uma cópia separada do arquivo de configuração. O objetivo é conseguir reverter a edição sem depender do próprio WordPress.

Como trocar as chaves de segurança do WordPress

1. Avise quem está usando o painel

A troca desconectará pessoas que estejam publicando conteúdo, processando pedidos ou atendendo clientes. Combine um horário e peça para todos salvarem o trabalho.

Em uma loja, evite fazer a alteração durante uma campanha ou no período de maior movimento. A sessão administrativa será afetada, mas integrações e fluxos de compra também precisam ser testados porque cada plugin pode manter estado de forma diferente.

2. Baixe uma cópia do wp-config.php

Localize o wp-config.php, normalmente na raiz da instalação ou em um diretório acima dela. Faça uma cópia antes de editar.

Não coloque esse arquivo em uma pasta pública do site. Ele pode conter credenciais do banco de dados e outras informações sensíveis. Também não envie a cópia por mensagem sem proteção adequada.

3. Gere novos valores em uma fonte confiável

Use o gerador oficial de chaves do WordPress. Cada acesso ao endereço apresenta um novo conjunto de valores aleatórios.

Abra o gerador em um dispositivo confiável. Não publique os valores em chamados, documentos compartilhados ou capturas de tela. As chaves do seu site devem permanecer privadas.

4. Substitua o conjunto completo

No wp-config.php, procure as oito definições de chaves e salts. Substitua o bloco atual pelo conjunto recém gerado.

Não misture parte das chaves antigas com parte das novas. Também não crie duas definições para a mesma constante. Se a hospedagem fornecer esses valores por variáveis de ambiente, confirme onde a configuração realmente é controlada antes de editar o arquivo.

Mantenha a estrutura original do arquivo. Não altere as credenciais do banco, o prefixo das tabelas ou outras constantes durante esta tarefa. Fazer uma mudança por vez facilita o diagnóstico.

5. Salve sem modificar o formato do arquivo

Use um editor de texto simples. Evite programas que adicionem formatação visual ou caracteres invisíveis.

Salve o arquivo e preserve as permissões anteriores. Uma permissão ampla demais pode expor dados. Uma permissão restrita de forma incorreta pode impedir que o servidor leia a configuração.

6. Entre novamente no painel

Abra uma janela privativa do navegador e acesse a página de login. Entre com uma conta administrativa válida.

Se o painel abrir, confirme também que uma sessão antiga foi encerrada. Faça o teste em outro navegador no qual você já estava conectado antes da alteração.

Como validar o site depois da troca

Não considere o trabalho concluído apenas porque a página inicial abriu. Verifique os pontos que dependem de autenticação e ações administrativas.

Use esta sequência:

1. abra a página inicial sem estar conectado;
2. entre no painel com uma conta administrativa;
3. edite um rascunho e salve a alteração;
4. envie um formulário de teste, se o site tiver formulários;
5. confira o acesso de um editor ou atendente;
6. verifique uma área restrita, se existir;
7. teste o carrinho e a conta do cliente em uma loja;
8. observe os registros de erro do servidor;
9. confirme que integrações importantes continuam respondendo.

Aplicativos conectados por senhas de aplicação usam um mecanismo diferente das chaves de cookies. Por isso, não conte com a rotação dos salts para revogar essas credenciais. Revise e remova separadamente as senhas de aplicação que não forem reconhecidas.

Problemas comuns e como recuperar o acesso

O site mostra uma tela de erro

A causa mais provável é um erro de sintaxe no wp-config.php. Restaure a cópia anterior e confirme se o site volta a funcionar. Depois, repita a alteração com atenção às aspas, parênteses e pontos e vírgulas.

O login entra em um ciclo de redirecionamento

Limpe os cookies do domínio e teste em uma janela privativa. Confirme também se os endereços do WordPress usam o domínio e o protocolo corretos. Problemas de HTTPS e cache podem parecer uma falha nas chaves.

Alguns usuários continuam conectados

Verifique se o arquivo editado pertence à instalação correta. Sites com cópias, subdomínios ou ambientes de teste podem ter arquivos diferentes. Limpe o cache de página e confirme se não existe uma camada servindo conteúdo administrativo indevidamente.

Uma integração parou de funcionar

Analise como ela autentica. Cookies, senhas de aplicação, tokens próprios e chaves de API são mecanismos diferentes. Consulte os registros antes de gerar novas credenciais sem necessidade.

O que a troca não resolve

Renovar chaves e salts é uma ação específica. Ela não remove arquivos maliciosos, não corrige plugins vulneráveis e não impede alguém que ainda tenha acesso ao servidor de ler os novos valores.

Depois de uma suspeita real, revise também:

• usuários administradores e funções atribuídas;
• contas de hospedagem, SSH e SFTP;
• senhas de aplicação do WordPress;
• plugins e temas desconhecidos;
• tarefas agendadas e arquivos alterados recentemente;
• regras do servidor e do arquivo .htaccess, quando aplicável;
• registros de login e atividade;
• cópias de backup anteriores ao incidente.

Se o objetivo for fortalecer o acesso diário, veja como proteger o login do WordPress e como ativar a autenticação de dois fatores. Essas medidas tratam riscos diferentes e podem ser usadas em conjunto.

Checklist de segurança após renovar as chaves

Antes de encerrar a manutenção, confirme:

• o conjunto completo de chaves foi substituído;
• não existem constantes duplicadas;
• o arquivo anterior está guardado em local privado;
• o site público abre sem erro;
• administradores conseguem entrar novamente;
• sessões antigas foram invalidadas;
• editores conseguem salvar conteúdo;
• formulários e áreas restritas foram testados;
• senhas de aplicação foram revisadas separadamente;
• acessos ao servidor foram conferidos;
• a equipe foi avisada sobre a necessidade de novo login.

Aproveite a revisão para conferir as permissões dos usuários no WordPress. Uma conta com privilégios excessivos amplia o impacto de uma credencial comprometida.

Perguntas frequentes sobre chaves e salts do WordPress

Trocar as chaves de segurança altera as senhas?

Não. As contas e senhas continuam cadastradas. Os usuários precisam apenas fazer login novamente porque os cookies anteriores deixam de ser válidos.

Todos os usuários serão desconectados?

As sessões autenticadas que dependem dos cookies assinados com os valores anteriores deixam de funcionar. Teste áreas restritas e integrações porque plugins podem manter sessões por mecanismos próprios.

Aplicativos conectados por senha de aplicação param de funcionar?

A troca das chaves não deve ser usada como forma de revogar senhas de aplicação. Revise essas credenciais na conta de cada usuário e remova as que não forem necessárias ou reconhecidas.

Com que frequência as chaves devem ser trocadas?

Não existe um intervalo universal que sirva para todos os sites. Faça a troca quando houver exposição, suspeita de acesso, mudança relevante de responsáveis ou como parte de um procedimento documentado de resposta a incidentes.

É possível desfazer a mudança?

Sim. Restaurar o conjunto anterior pode fazer cookies antigos voltarem a ser aceitos, desde que ainda existam e sejam compatíveis. Em um incidente, isso pode reabrir sessões que você pretendia invalidar. Use a restauração apenas para corrigir um erro técnico e gere um novo conjunto assim que o site estiver estável.

Próximo passo para proteger os acessos

Depois de renovar as chaves, revise quem ainda pode administrar o site. Remova contas sem uso, reduza privilégios desnecessários e ative autenticação de dois fatores para funções sensíveis.

A troca das chaves é mais eficaz quando faz parte de uma rotina que inclui atualização, backup, monitoramento e controle de acessos. Sozinha, ela encerra sessões antigas. Com uma revisão do ambiente, ajuda a reduzir a possibilidade de o mesmo problema continuar ativo.