Primeiro, tente entender como a autenticação SSL (HTTPS) e HTTP funciona.
Os métodos de autenticação HTTP usuais (Digest, Basic e qualquer esquema de autenticação baseado em cookies e formulários que você possa implementar sobre HTTP) são todos inseguros por si próprios, porque enviam informações de autenticação mais ou menos em texto não criptografado. Se os dados estão em campos ou cabeçalhos POST e se a codificação base64 é aplicada, não importa a esse respeito, a senha é claramente visível para qualquer pessoa com acesso ao tráfego de rede. Isso significa que a autenticação HTTP em um canal não confiável não vale nada: basta que um invasor leia sua senha é um pouco de cheirar a rede.
O SSL implementa um canal de comunicação seguro em um canal inerentemente inseguro. Isso funciona, grosso modo, da seguinte maneira:
- Servidor envia um certificado assinado
- O cliente valida o certificado em uma lista de chaves de assinatura em bom estado; as assinaturas de certificado podem ser encadeadas, para que cada nó diga "se a assinatura que me assina é boa, eu também sou", mas, finalmente, a cadeia precisa resolver para uma das poucas autoridades confiáveis pré-configuradas no cliente.
- O cliente usa a chave de criptografia pública do servidor para enviar um segredo compartilhado
- O servidor descriptografa o segredo compartilhado usando a chave privada (porque apenas o servidor legítimo possui a chave privada, outros servidores não poderão descriptografar o segredo compartilhado)
- O cliente envia dados de solicitação reais, criptografados usando o segredo compartilhado
- O servidor descriptografa os dados da solicitação e envia uma resposta criptografada
- O cliente descriptografa a resposta e a apresenta ao usuário.
Observe alguns pontos importantes aqui:
- A cadeia de certificados permite que os clientes tenham certeza de que o servidor com o qual estão conversando é o real, não alguém que intercepte suas solicitações. É por isso que você deve comprar um certificado SSL real e por que os navegadores emitem avisos assustadores quando você acessa um site que usa um certificado inválido, expirado ou incorreto: toda a criptografia do mundo não ajuda se você estiver conversando com a pessoa errada.
- A criptografia pública / privada usada para trocar o segredo garante que a comunicação bem-sucedida funcione apenas entre esse par específico de cliente e servidor: os pacotes de rede detectados serão criptografados e exigirão que a chave privada do servidor obtenha os dados.
- A criptografia simétrica é usada para a maior parte da solicitação, porque possui uma sobrecarga de desempenho muito menor que a criptografia de chave pública / privada. A chave (segredo compartilhado) é trocada usando criptografia de chave pública / privada, porque essa é a única maneira de fazê-lo de maneira segura (exceto transportando-a por um canal separado, como um serviço de correio).
Então, obviamente, há alguma sobrecarga envolvida, mas não é tão ruim quanto você pensa - é principalmente na escala em que "jogar mais hardware" é a resposta apropriada, a menos que você esteja se preparando para quantidades absolutamente enormes de tráfego ( pense no Google ou no Facebook). Em circunstâncias normais, ou seja, no uso típico de aplicativos da Web, a sobrecarga do SSL é desprezível e, consequentemente, assim que você tiver dados confidenciais, é melhor executar tudo em SSL, incluindo recursos. SSL também é a única maneira viável de proteger o tráfego HTTP; outros métodos simplesmente não são tão padronizados e, portanto, não são amplamente suportados, e você absolutamente não deseja implementar essas coisas sozinho, porque, honestamente, é muito fácil cometer erros.
TL; DR: Sim, a autenticação básica SSL + é uma boa ideia, sim, você precisa de um servidor seguro (e um certificado válido ); sim, isso atrasará um pouco as coisas, mas não, isso não é algo para se preocupar corretamente agora.