Sniffing wordpress user’s credentials

Chegando ao desenvolvimento do WordPress a partir de um desenvolvimento mais “hardcore” (lento), acho extremamente estranho que o processo de login do WordPress não ofereça absolutamente nenhuma defesa contra os dados de credenciais de cheirar.

Tudo funciona em texto simples, o que torna extremamente fácil pescar credenciais de login de qualquer pessoa em um WiFi público, incluindo administradores, se o site não tiver nenhum SSL instalado.

Mesmo a busca de plugins que podem criptografar os dados antes de enviá-lo para o servidor foi inútil.

Então, o que há de WordPress? É considerado uma boa prática instalar SSL em todos os sites? É considerado OK apenas fazer login com sua conta de administrador no WiFi público, independentemente se seu site tiver SSL instalado? E quanto ao processo de login / registro de outros usuários? Ele coloca a maioria dos sites da WordPress e seus usuários com um grande risco de segurança, parece não usar criptografia SSL.

Solutions Collecting From Web of "Sniffing wordpress user’s credentials"

O processo de login não é tão importante, é uma coisa única que, com as configurações corretas, você pode fazer uma vez por ano.

O que é importante são os cookies de autenticação que estão sendo enviados. Enquanto não estiverem criptografados, não importa em absoluto quanto de defesa você coloca no próprio formulário de login e os cookies são enviados toda vez que um dos URLs do site está sendo buscado.

Então, você tem SSL ou não está seguro. Há um termo intermediário no wordpress no qual você obterá URLs HTTPS automaticamente para usuários conectados (e o formulário de login), mas, obviamente, você ainda precisa de um certificado.

Por que alguém não usaria HTTPS quando a ameaça de Wi-Fi é conhecida e o custo de um certificado é zero? porque o custo do certificado “livre” está perdendo tempo para configurá-lo e administrá-lo, e enquanto a ameaça WiFi existe, ninguém mostrou que usar o WiFi é menos seguro do que ter uma conta no Yahoo e a maioria das pessoas não se conecta um Wifi externo para seus sites. Pessoalmente, eu uso meus dados celulares, mesmo quando o WiFi livre está disponível.

Há também outros benefícios de não executar um site HTTPS completo, especialmente o armazenamento em cache. Quando você faz HTTPS, seu conteúdo não pode ser armazenado em cache.

Então, sim, a indústria (google) tenta torná-lo um caso de branco e preto, mas, na realidade, é (como a maioria das coisas) cinza. Todo mundo tem que avaliar seus próprios riscos de segurança e compará-lo com a quantidade de trabalho necessário para superá-lo e tomar sua própria decisão

Disclaimer: Leve tudo isso com uma pitada de sal, pois não sou um especialista em segurança.

Tudo isso não é diferente para o WP do que para qualquer outra coisa. Se você não usar SSL, todos os que podem interceptar o tráfego podem pescar qualquer coisa transmitida. Você pode obter SSL ou viver com o risco. Então, isso provavelmente está fora do tópico aqui mesmo, pois não é específico para o WP.

Sua idéia de criptografar antes da transferência – eu realmente não entendo. A menos que você esteja usando um Plugin do Navegador que lida com isso, o código que pode criptografar a senha vem de um servidor no qual você não pode confiar. Então, um invasor precisaria enviar uma JS manipulada que vazou a senha em vez de apenas ouvir o tráfego. Talvez um pouco mais difícil, mas ainda basicamente o mesmo.

TLDR; Se você deseja que seu site seja seguro, obtenha SSL. Caso contrário, viva com os riscos ou pelo menos evite redes hostis (por exemplo, wifi público).

Além da resposta @ MarkKaplun por aqui que responde a questão real, pensei que gostaria de adicionar a perspectiva do hacker sobre o assunto. Eu não sou um “especialista” de segurança, mas tenho alguma experiência nisso. Deixe-me explicar.

Se eu estivesse fazendo um ataque MiTM na rede onde os referidos usuários são, eu primeiro examinaria os pacotes não SSL, que não são criptografados. Agora, digamos que encontro uma chave de formulário, para a qual também encontro um valor ilegível. Minha primeira intuição seria buscar o referente, ir ao referente e reverter o código JS que o faz.

Você poderia, obviamente, me atrapalhar com as aplicações de flash / java, mas você não vai fazer isso assim mesmo, vai assustar seus visitantes (a menos que você tenha algo de particular, certo?).

Mesmo que você habilite o SSL na página de login, eu tentaria fazer o usuário aceitar meu certificado falso. Ao fazê-lo, resultará na divulgação completa de informações desse cliente em particular.

O ponto é ter SSL e uma política de login muito rígida habilitada em vez de um formulário criptografado, porque você não pode criptografar isso em última análise no lado do cliente. Se o seu usuário for um fantoche, ele / ela continuará sendo um …