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

Question

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

Meu entendimento é que em qualquer um dos saltos ao longo do caminho você pode usar um analisador de pacotes para ver o que está sendo enviado . Isto 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. Está certo?

Supondo que o sabor desse requisito de subrede 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 qualquer um poderia estar escutando. Eu deveria estar preocupado com o que está acontecendo nas sub-redes que os pacotes viajam do lado de fora? Eu não sei muito sobre o tráfego de rede, mas eu diria que ele está fluindo pelos data centers das principais operadoras e não há muitos vetores de ataque por aí, mas por favor me corrija se eu estiver errado. / p>

Existem outros vetores para se preocupar fora de alguém que esteja ouvindo com um analisador de pacotes?

Eu sou um profissional de redes e segurança, então sinta-se à vontade para me esclarecer se estou usando a terminologia errada em qualquer um desses termos.

    

Answer 1

Algo a se notar que outros não mencionaram aqui é que alguns navegadores armazenam em cache seus dados de formulário. O comportamento padrão em sites SSL normalmente é não armazenar nada em cache, a menos que você escolha "salvar minha senha". Normalmente, os campos de senha não são armazenados de qualquer maneira, mas eu já vi algumas esquisitices (geralmente informações de cartão de crédito, que eu sei que não são realmente o tópico da pergunta).

A outra coisa a notar é que a criptografia SSL começa no handshake TCP. Uma vez sob SSL, não é possível distinguir HTTP sobre SSL de FTP por SSL (além de suposições feitas por meio do número da porta).

Você também não pode distinguir uma solicitação de login de uma solicitação "Im just browsing", isso ofusca o fluxo de página de possíveis hackers e também garante que seus dados de senha não sejam seguros, mas seus dados de histórico de navegação / cookie / e qualquer informação pessoal que acompanhe a sua conta.

No geral, se você eliminar os ataques man-in-the-middle do espectro, reduzirá muitos dos possíveis ataques, o que não significa que o site seja ' seguro 'embora. Também a política de zoneamento deve ajudar a proteger você dos ataques XSS, já que você fará uma alteração de zona se o usuário for redirecionado para fora do seu site.

    

Answer 2

Os dados são vulneráveis em qualquer lugar ao longo do trajeto, não apenas no primeiro ou no último estágio. É bastante concebível que um sistema envolvido na transferência pesquise nomes de usuário, senhas e outros dados confidenciais. Segue-se, portanto, que os dados sensíveis devem viajar apenas por um link que esteja protegido até o fim e, é claro, é exatamente para isso que o SSL serve. Dependendo de quais dados estão envolvidos, pode haver leis locais que ditam o SSL.

    

Answer 3

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 não seguro pode comprometer a senha do seu homebank, por exemplo.

    

Answer 4

Sua análise é razoável, IMHO.

A coisa a notar, suponho, é que pode haver caches em 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, a coisa a considerar é que a maioria do acesso à rede ocorre em uma área onde há muitas outras pessoas na mesma rede. Trabalho / Uni / Escola sendo os principais exemplos. Em casa, você poderia argumentar que é menos arriscado, porque são apenas caminhos que você precisa se preocupar.

Mas realmente, não há dúvida aqui. Você usa SSL ao fazer login. Provavelmente, o argumento mais convincente para o cara é que ele faz com que seu site pareça mais confiável, já que - o ideal é que o público em geral nunca faça login em um site que não tenha 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.

    

Answer 5

Eu posso concordar com as reflexões de KevinM em responder suas próprias perguntas, e John Gardeniers está apontando na direção correta. Eu também devo concordar com o que Silky disse, "idealmente - o público em geral nunca logaria em um site que não tenha uma tela de login baseada em SSL", e ressalte que este não é, no entanto, o caso contemporâneo. em tudo.

Não concordo com o 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 nenhum conceito de necessidade de SSL, e essa é a sua pessoa comum em poucas palavras. Eles não são estúpidos, eles simplesmente não sabem. Para dizer "você precisa disso", a resposta será ilícita, "Eu vivi x anos sem isso, e vou viver x mais bem", ou talvez até uma resposta pior, "eu odeio ouvir o que eu preciso " Então, tenha cuidado!

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

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

    

Answer 6

em todo o percurso seguido por pacote, se o seu HTTP puder ser detectado e os dados puderem ser vistos ... mesmo se você usar HTTP em Proxy como TOR ... usando ataque de coleta, etc. pode-se enganar o Proxy para vazar os pacotes de dados ... então, se houver algo próximo de sensível (senhas, detalhes pessoais, imagens privadas, etc.) ... só é adequado transferi-los por HTTPS.

Isso também, mesmo o HTTPS é vulnerável com implementação incorreta e há vários Ataques SSL aplicáveis sobre ele ... ainda assim, isso pode ser evitado com uma implementação cuidadosa.

Mas, usar HTTP para texto simples é como convidar até mesmo os novatos n / w kids a farejarem as senhas.