Atualmente estou trabalhando em um provedor PHP OpenID que funcionará em HTTPS (portanto, criptografado com SSL).
É errado transmitir a senha em texto simples? HTTPS em teoria, não pode ser interceptado, então não vejo nada de errado. Ou isso é inseguro em algum nível e não estou conseguindo ver isso?
Respostas:
É seguro. É assim que toda a web funciona. Todas as senhas em formulários são sempre enviadas em texto simples, portanto, cabe ao HTTPS protegê-lo.
Você ainda precisa certificar-se de enviá-lo via solicitação POST, não GET. Se você enviá-lo por meio de uma solicitação GET, ele pode ser salvo em texto simples nos registros de histórico do navegador do usuário ou nos registros de acesso do servidor web.
Se o HTTP estiver desabilitado e você usar apenas HTTPS, então você não está realmente transmitindo a senha como texto simples.
Hash do lado do cliente. Por quê? Deixe-me contar sobre um pequeno experimento. Vá até o computador no refeitório da empresa. Abra o navegador para acessar a página de login do site da empresa (https). Pressione F12, clique na guia de rede, marque o log de persistência, minimize o console, mas deixe a página da web aberta para a página de login. Sente-se e almoce. Observe o funcionário depois que ele se conecta ao site da empresa e, sendo um bom trabalhador, faz o logout ao terminar. Termine o almoço, sente-se no computador, abra a guia de rede e veja cada nome de usuário e senha em texto simples no corpo do formulário.
Sem ferramentas especiais, sem conhecimento especial, sem hardware sofisticado de hackers, sem keyloggers, apenas o bom e velho F12.
Mas ei, continue pensando que tudo que você precisa é SSL. Os bandidos vão adorar você por isso.
Vamos fazer algumas anotações sobre as respostas anteriores.
Primeiro, provavelmente não é a melhor ideia usar algoritmos de hash no lado do cliente. Se sua senha for salted no lado do servidor, você não será capaz de comparar hashes (pelo menos não se você não armazenar o hash do cliente no banco de dados em uma das camadas de hash da senha, que é a mesma ou pior). E você não quer implementar o algoritmo de hash usado pelo banco de dados no lado do cliente, seria bobagem.
Em segundo lugar, a troca de chaves criptográficas também não é ideal. O MITM poderia teoricamente (considerando que ele tem um certificado raiz instalado no cliente) alterar as chaves criptográficas e alterar com suas próprias chaves:
Conexão original (sem considerar tls) de um servidor teórico que troca chaves:
Cliente solicita chaves públicas> servidor mantém as chaves privadas, gere chaves públicas para cliente> servidor envia chaves públicas para cliente
Agora, em uma abordagem teórica do MITM:
Cliente solicita chaves públicas> MITM gera chaves privadas falsas > Servidor mantém as chaves privadas, gera chaves públicas para o cliente> MITM recebe as chaves públicas do servidor original, agora, estamos livres para enviar nossas chaves públicas falsas para o cliente, e sempre que uma solicitação vier do cliente, iremos descriptografar os dados do cliente com as chaves falsas, alterar a carga útil (ou lê-la) e criptografar com as chaves públicas originais > MITM envia chaves públicas falsas para o cliente.
Esse é o ponto de ter um certificado de CA confiável em TLS e é assim que você recebe uma mensagem do navegador avisando se o certificado não é válido.
Em resposta ao OP: na minha humilde opinião você não pode fazer isso, porque mais cedo ou mais tarde alguém vai querer atacar um usuário do seu serviço e vai tentar quebrar o seu protocolo.
O que você pode fazer, no entanto, é implementar 2FA para evitar que as pessoas tentem fazer login com a mesma senha. Alerta para ataques de repetição, no entanto.
Não sou muito bom com criptografia, corrija-me se estiver errado.
Os outros pôsteres estão corretos. Agora que você está usando SSL para criptografar a transmissão da senha, certifique-se de fazer o hash com um bom algoritmo e salt para que fique protegido quando estiver em repouso também ...
O exemplo de @CodeDog tem problemas ..
Sim, posso acreditar que os usuários farão login em uma caixa de cafeteria. Se você está capturando logs de uma cafeteria corporativa, você é a falha de segurança. Caixas de cafeterias corporativas devem ser configuradas desabilitadas, por exemplo, sem termos, sem loggers, sem acesso remoto, etc. Para prevenir você, o hacker interno.
O exemplo é um bom exemplo de segurança de acesso ao computador, e não está realmente relacionado à segurança de rede. É fornecido como justificativa para o hashing do lado do cliente, mas se você tiver acesso ao computador, pode simplesmente usar um registrador de pressionamento de tecla e ignorá-lo. O hash do lado do cliente é novamente irrelevante. O exemplo de @CodeDog é um hack de acesso ao computador e requer técnicas diferentes dos hacks da camada de rede.
Além disso, um hack de computador público é protegido ao incapacitar o sistema de ameaças, conforme mencionado acima. por exemplo, use um Chromebook para um computador público de cafeteria Mas isso é contornado por um hack físico . Durante as horas de folga, vá até a cafeteria e configure uma câmera secreta para gravar os pressionamentos do teclado pelos usuários. Então não importa se o computador da cafeteria está danificado OU que tipo de criptografia é usada.
camada física -> camada do computador -> camada do cliente -> camada de rede -> camada do servidor
Para rede, não importa se você hash no lado do cliente, porque a camada https / ssl criptografará o passwd simples. Portanto, como outros mencionam, o hashing do cliente é redundante se o TLS for seguro.