Quais são os vetores de ataque para senhas enviadas por http?

Estou tentando convencer um cliente a pagar por SSL para um site que requer login. Quero ter certeza de que entendi corretamente os principais cenários nos quais alguém pode ver as senhas que estão sendo enviadas.

Meu entendimento é que, em qualquer um dos saltos ao longo do caminho, é possível usar um analisador de pacotes para visualizar o que está sendo enviado. Isso parece exigir que qualquer hacker (ou seu malware / botnet) esteja na mesma sub-rede que qualquer um dos saltos que o pacote leva para chegar ao seu destino. Isso está certo?

Supondo que um certo sabor desse requisito de sub-rede seja verdadeiro, preciso me preocupar com todos os saltos ou apenas com o primeiro? O primeiro com o qual eu obviamente posso me preocupar se eles estiverem em uma rede Wi-Fi pública, já que alguém pode estar ouvindo. Eu deveria estar preocupado com o que está acontecendo nas sub-redes pelas quais os pacotes trafegam fora disso? Não conheço muito o tráfego de rede, mas suponho que ele esteja fluindo pelos datacenters das principais operadoras e que não haja muitos vetores de ataque por lá, mas corrija-me se estiver errado.

Existem outros vetores com os quais se preocupar fora de alguém ouvindo com um analisador de pacotes?

Eu sou um noob de rede e segurança, por isso, sinta-se à vontade para me esclarecer se estiver usando a terminologia errada em algo disso.

Algo para anotar que outros não mencionaram aqui é que alguns navegadores armazenam em cache os dados do seu formulário. O comportamento padrão nos sites SSL geralmente é não armazenar nada em cache, a menos que você tenha escolhido "salvar minha senha". Geralmente, os campos de senha não são armazenados em cache de qualquer maneira, mas já vi algumas esquisitices (normalmente informações de cartão de crédito, que eu sei que não são realmente o assunto da pergunta).

A outra coisa a observar é que a criptografia SSL inicia no handshake TCP. Uma vez sob SSL, você não pode distinguir HTTP sobre SSL de FTP sobre SSL (além de suposições feitas através do número da porta).

Você também não pode distinguir uma solicitação de login de uma solicitação "Estou apenas navegando", isso ofusca o fluxo da página de possíveis hackers e também garante que não apenas seus dados de senha sejam seguros, mas também seu histórico de navegação / dados de cookies e qualquer informações pessoais que acompanham sua conta.

Tudo em tudo, se você eliminar os ataques man-in-the-middle do espectro, reduzirá muitos dos ataques em potencial, isso não quer dizer que seu site seja "seguro". A política de zoneamento também deve ajudar a protegê-lo contra ataques XSS, pois você fará uma alteração de zona se o usuário for redirecionado para fora do site.

Os dados são vulneráveis ​​em qualquer lugar ao longo da rota, não apenas no primeiro ou no último estágio. É perfeitamente concebível que um sistema envolvido na transferência procure nomes de usuário, senhas e outros dados confidenciais. Conclui-se, portanto, que os dados confidenciais só devem passar por um link protegido por toda a extensão e, é claro, é exatamente para isso que serve o SSL. Dependendo dos dados envolvidos, é possível que haja leis locais que determinam o SSL.

Existem servidores proxy que podem armazenar dados.

Mas também existe a obrigação de manter as senhas dos usuários seguras. Muitos usuários usam um conjunto limitado de senhas; portanto, um site inseguro pode comprometer sua senha do homebank, por exemplo.

Sua análise é razoável, IMHO.

O que deve ser observado, suponho, é que pode haver caches no seu caminho. Portanto, pode ser que a solicitação seja registrada em algum lugar (especialmente se o login for GET, o que seria terrível).

Provavelmente, o que deve ser considerado é que a maioria dos acessos à rede ocorre em uma área onde existem muitas outras pessoas na mesma rede. Trabalho / Uni / Escola são os principais exemplos. Em casa, você pode argumentar que é menos arriscado, porque são apenas caminhos para o qual você precisa se preocupar.

Mas, realmente, não há dúvida aqui. Você usa SSL ao fazer login. Provavelmente, o argumento mais convincente para esse cara é que ele faz com que seu site pareça mais confiável, pois - idealmente - o público em geral nunca faria login em um site que não possui uma tela de login baseada em SSL .

Mas vamos ser realistas. Quase certamente esse vetor de ataque não é o modo como seu sistema ou usuários serão comprometidos.

HTH.

Posso concordar com as reflexões de KevinM em responder às suas próprias perguntas, e John Gardeniers está apontando na direção correta. Devo também concordar com o que a seda disse, em "idealmente - o público em geral nunca efetuaria login em um site que não possua uma tela de login baseada em SSL". em absoluto.

Discordo do tom sedoso (provavelmente não intencional), que leva à percepção onipresente de que "o público em geral" é estúpido. O cliente de KevinM claramente não tem o conceito de necessidade de SSL, e essa é uma pessoa comum em poucas palavras. Eles não são estúpidos, eles simplesmente não sabem. Dizer: "você precisa disso" ilicará a resposta: "Eu vivi x anos sem ela e viverei x mais bem", ou talvez até uma resposta pior ", odeio ser informado do que preciso . " Por isso tem cuidado!

Sua preocupação é legítima, Kevin. Seu cliente precisa de um certificado SSL. Eu acho que sua verdadeira preocupação deveria ser como vendê-los um. Não são apenas os logins de usuários com os quais se preocupar, mas os logins de administrador e operador que também se beneficiariam da proteção por SSL.

Sim, há outras coisas com que se preocupar a esse respeito, mais ainda do que cheirar pacotes, como o XSS . Eles são numerosos e bem documentados .

em toda a rota seguida pelo pacote, se o seu over HTTP puder ser detectado e os dados puderem ser vistos ... mesmo se você usar HTTP no Proxy como o TOR ... usando o ataque de colheita, etc. pode-se enganar o Proxy para vazar os pacotes de dados ... por isso, se houver algo próximo de confidencial (senhas, detalhes pessoais, imagens privadas, etc.) ... é adequado transferi-los por HTTPS.

Isso também, até o HTTPS é vulnerável à implementação incorreta e há vários ataques SSL aplicáveis ​​a ele ... ainda assim, esses podem ser evitados com uma implementação cuidadosa.

Porém, usar HTTP para texto sem formatação é como convidar até mesmo os novatos com filhos a descobrir as senhas.