O SSL realmente importa para a maioria dos sites?


11

Fiquei bastante paranóico em aprender a "fazer a segurança certa" para este site que estou construindo (primeiro site não trivial que criei) e notei algo que me incomoda: SSL.

Eu li muitos tópicos de segurança aqui, no StackOverflow, e em outros lugares sobre a regeneração dos IDs de sessão após n usos, e como suas senhas precisam ser salgadas, colocadas em hash e nunca armazenadas em texto sem formatação. Eu já li bastante sobre como detectar quando uma sessão foi invadida, rastreando endereços IP, agentes de usuários e usando cookies de rastreamento.

O que eu não entendo é o que isso importa quando o site efetua login por meio de um POST HTTP normal e envia sua senha por fio em texto sem formatação?

Entendo que todos os outros métodos que listei são necessários para reduzir sua exposição geral, e talvez haja alguns sites que não precisem de tanta segurança, mas acho que estou perguntando:

  • Quando é bom não se preocupar com SSL?

Sites como o Gmail, o seu banco e o LinkedIn, vejo motivos para usar o SSL, mas o que faz com que seja legal que sites como o Facebook e o reddit não se incomodem (inferno, o PlentyOfFish até armazena sua senha em texto sem formatação e até envia por e-mail semanalmente como lembrete!?!)?

Quão preocupado devo estar em garantir que o SSL esteja configurado (especialmente porque eu começaria com um host compartilhado e estou começando a ser muito barato)? Meu site não conterá nenhuma informação particularmente pessoal, se isso ajudar. Se o site se tornar um sucesso, eu consideraria seriamente pagar o extra pela segurança adicional.

Respostas:


7

É tão importante quanto você e seus usuários pensam que é importante. O envio de senhas por http como texto sem formatação os deixa vulneráveis ​​à detecção de pacotes. Agora, se alguém realmente se incomodará em cheirar esses pacotes é outra história. Se você deseja garantir a seus usuários a experiência mais segura possível, use SSL para os envios de logon. Se você acha que seus usuários ficarão mais felizes e mais propensos a interagir com seu site de maneira positiva (por exemplo, comprar coisas, fazer coisas etc.), use o SSL para os envios de login. Se você tem algo que vale a pena roubar (ou seja, informações do usuário), use o SSL.

Se você não tem nada que valha a pena roubar, não pense que o SSL aprimorará muito ou nada a segurança, ou se seus usuários não o verão como um recurso útil, considere não usar o SSL.

Pelo custo da instalação de um certificado SSL, a menos que você esteja com um orçamento apertado, nunca é uma coisa ruim garantir o login de um site. E não deixe que o que os outros sites estão fazendo influencie você, já que muitos sites grandes não seguem as práticas recomendadas, e é por isso que há um fluxo constante de notícias sobre alguém que está sendo comprometido de alguma forma.


1
+1 "muitos sites maiores não necessárias melhores práticas seguem" - Tenho certeza de que haverá algumas manchetes risíveis quando 419'ers nigerianos descobrir uma maneira de rentabilizar perfis de namoro site roubados :)
danlefree

"a menos que você esteja com um orçamento apertado" - mas estou. Estou realmente, realmente, a ponto de pensar em usar m + m em um host compartilhado barato, em vez de pagar consideravelmente menos por mês para pagar um ano adiantado. Dessa forma, eu posso desligar o site se o site não começar a se pagar de forma relativamente rápida. Acho que por enquanto estou me inclinando para o no-ssl, já que apenas obter o IP estático necessário sozinho quase dobraria meu custo mensal, sem mencionar o custo do próprio certificado. O site está muito perto de ser um fórum e a maioria dos dados é pública, portanto, não há necessidade de criptografia fora do login.
AgentConundrum

@danlefree, isso é fácil. Use os detalhes pessoais nos sites de namoro para responder às perguntas de recuperação de senha dos sites de email e banco dos usuários. Ou apenas capture a senha, já que as pessoas reutilizam suas senhas, em grande parte.
Zoredache

O @AgentConundrum Startssl oferece um certificado SSL de graça. Se você tem um orçamento apertado, mas tem um IP estático, pode optar por isso.
Rana Prathap 28/08

@AgentConundrum, você não precisa mais de um IP dedicado para SSL, desde que seu host ofereça suporte ao SNI (e, se não, encontre um novo host porque não sabe o que está fazendo). Você pode obter um certificado de graça, para que não é um custo adicional ou ...
Doktor J

3

Tomando a abordagem oposta à resposta de John, acho que você deve considerar seriamente o SSL se manipular qualquer informação de identificação pessoal - para incluir: nomes com endereços físicos, endereços de email, informações financeiras e comunicações que os usuários razoavelmente esperariam que fossem privadas .

A menos que seu site forneça meios para que os usuários publiquem informações sobre si mesmos, considere que todas as informações de identificação pessoal fornecidas por eles sejam mantidas por você e somente sob estrita confiança, a menos que a política de privacidade do site informe seus usuários de outra forma.

Impedir que terceiros não autorizados vejam as informações de seus visitantes e mantenha seus usuários informados sobre como você usa essas informações para manter a confiança de seus visitantes.

Até o Facebook faz isso, até onde eu sei.

<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit=";var d=document.documentElement;if (d.onsubmit) { return d.onsubmit(event); }else { return Event.fire(d, &quot;submit&quot;, event); }">

(Fonte HTML de login do Facebook.com)


Ímpar. Não sei como não percebi isso no Facebook. Eu estava olhando para ele no HTTPFox e de alguma forma perdi o 's' na solicitação inicial. Vou editar para remover isso. Ainda é verdade que muitos sites fazem isso (reddit, notícias de hackers, TDWTF etc.), então, na pior das hipóteses, eu não seria melhor que eles. O orçamento é uma grande preocupação minha, portanto, gastar um extra de US $ 5 / mês por um IP estático (em um host de US $ 8 / mês ...) e comprar um certificado decente. local.
AgentConundrum

@AgentConundrum - Estritamente falando, não há problema em passar uma senha executada através de um algoritmo de hash unidirecional por HTTP se a senha for salgada, por isso não ficaria surpreso ao ver uma implementação de hash MD5 em sites que não estão utilizando SSL: pajhome.org.uk/crypt/md5
danlefree

e como a construção de um hash no lado do cliente ajudaria alguma coisa? Nesse caso, basicamente o hash é a senha . Deveria conseguir capturar o hash e reproduzi-lo tão facilmente quanto possível capturar uma senha.
precisa saber é o seguinte

1
@ Zoredache É por isso que o hash deve ser salgado . Eis como funciona: envio a página de login com um token pré-preenchido, que inclui uma microtime()chamada do servidor. Seu hash transmitido é uma combinação de sua senha + microtime()e, assim que eu receber seu hash, invalido o microtime()par de desafio / resposta + senha (ele não pode ser usado novamente).
Danlefree 22/09/10

3

Em agosto de 2014, o Google indicou oficialmente que o HTTPS seria usado como um sinal de classificação.

Isso significa que, mesmo que seu site seja totalmente estático, se você se preocupa com o SEO, considere a possibilidade de configurar um certificado SSL.

É claro que o HTTPS é apenas um sinal de classificação dentre centenas, então provavelmente há coisas mais importantes que você pode fazer pelo SEO.


O Google também anunciou que, uma vez que a configuração de um certificado SSL requer recursos, você precisará fazer isso apenas se o site exigir. Em resumo, eles mencionaram que suas classificações não serão afetadas apenas porque você não configurou um certificado SSL em seu blog pessoal.
Rana Prathap 28/08

1

Aqui está um ângulo que você pode não ter considerado: não usar SSL / TLS pode expor seus usuários a monitoramento passivo, mesmo que seu site não possua logins.

Um agente de ameaça pode simplesmente ficar entre o usuário e o resto da Internet, observando todos os URLs solicitados pelo usuário e criando padrões do que o usuário está visualizando. De fato, bits individuais de informação podem ser insignificantes isoladamente, mas a combinação de muitos pequenos bits de informação pode criar uma imagem muito maior.

É por esse motivo que ofereço HTTPS no meu próprio site, que fornece apenas conteúdo estático.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.