Existem muitos sites na Internet que exigem informações de login, e a única maneira de proteger contra a reutilização de senhas é a "promessa" de que as senhas são criptografadas no servidor, o que nem sempre é verdade.
Então, eu me pergunto, o quão difícil é criar uma página da Web que coloque senhas no computador cliente (com o Javascript), antes de enviá-las ao servidor, onde elas seriam re-hashed? Em teoria, isso não oferece segurança extra, mas, na prática, isso pode ser usado para proteger contra "sites maliciosos" que não codificam sua senha no servidor.
Por que não é usado? Porque é muito trabalho extra para ganho zero. Tal sistema não seria mais seguro. Pode até ser menos seguro porque dá a falsa impressão de ser mais seguro, levando os usuários a adotarem práticas menos seguras (como reutilização de senha, senhas de dicionário, etc.).
In theory this doesn't give any extra security, but in practice this can be used to protect against "rogue sites" that don't hash your password in the server.
Como exatamente isso protege você? Parece que tudo que você quer fazer é hash a senha com hash que é meio sem sentido. Porque a senha com hash se tornaria a senha.
There are many sites on the Internet that require login information, and the only way to protect against password reusing is the "promise" that the passwords are hashed on the server, which is not always true.
Que tal não usar a mesma senha para mais de um site? A razão pela qual os sites usurpam a senha, em teoria, é impedir o acesso à sua conta, caso ELES sejam comprometidos. Usar a mesma senha para vários sites é simplesmente estúpido.
Se você usou javascript, tudo o que o "hacker" teria que fazer é usar o mesmo método nas senhas com hash com hash. Uma vez que você tenha as informações em hash, é apenas o tempo necessário para calcular o mesmo hash no banco de dados que é um fator que impede o acesso a uma conta.
Porque isso acrescentaria pouco ou nenhum valor. A razão disso é que, se o seu banco de dados for hackeado, o hacker não terá uma lista de senhas válidas, apenas hashes. Portanto, eles não podem representar qualquer usuário. Seu sistema não tem conhecimento da senha.
O seguro vem de certificados SSL, além de alguma forma de autenticação. Eu quero que meus usuários forneçam uma senha para que eu possa calcular o hash dela.
Além disso, o algoritmo de hashing estaria no servidor em uma área mais segura. Colocando-o no cliente, é muito fácil obter o código-fonte para Javascript, mesmo que seus arquivos de scripts de referência ocultos.
A solução é mais simples que isso. Certificados de cliente. Eu crio um certificado de cliente na minha máquina. Quando me registro em um site, fazemos um handshake usando meu certificado de cliente e o certificado do servidor.
Nenhuma senha é trocada e, mesmo que alguém hackeie o banco de dados, tudo o que eles terão é a chave pública do meu certificado de cliente (que deve ser salgada e criptografada pelo servidor para um nível adicional de segurança).
O certificado de cliente pode ser armazenado em um cartão inteligente (e enviado para um cofre online seguro usando uma senha mestra).
A beleza de tudo é que elimina o conceito de phishing ... você nunca está digitando uma senha em um site, você está apenas apertando o site. Tudo o que eles recebem é sua chave pública, que é inútil sem uma chave privada. A única suscetibilidade é encontrar uma colisão durante um aperto de mão e isso só funcionaria uma vez em um único site.
A Microsoft tentou fornecer algo parecido com isso no Windows com o Cardspace e depois o submeteu como um padrão aberto. OAuth é um pouco semelhante, mas depende de uma "parte emissora" intermediada. Os InfoCards, por outro lado, podem ser auto-emitidos. Essa é a solução real para o problema da senha ... removendo senhas completamente.
OAuth é um passo na direção certa.
A maioria das respostas aqui parece perder completamente o ponto de hashing de senha do lado do cliente.
o ponto é não para proteger o acesso ao servidor no qual você está efetuando login, já que interceptar um hash não é mais seguro do que interceptar uma senha de texto simples.
o ponto é realmente proteger a senha do usuário , que geralmente é muito mais valiosa do que o acesso individual ao site, já que a maioria dos usuários reutiliza sua senha para vários sites (eles não deveriam, mas a realidade é que eles fazem isso não deve ser descartado).
Ossl é ótimo para proteger contra ataques de mitm, mas se um aplicativo de login for comprometido no servidor, o ssl não protegerá seus usuários. se alguém tiver acesso malicioso a um servidor da Web, provavelmente conseguirá interceptar senhas em texto simples, pois, na maioria dos casos, as senhas só são criptografadas por um script no servidor. então o invasor pode experimentar essas senhas em outros sites (geralmente mais valiosos) usando nomes de usuários semelhantes.
a segurança é a defesa em profundidade, e o hashing do lado do cliente simplesmente adiciona outra camada. lembre-se de que, embora seja importante proteger o acesso ao seu próprio site, proteger o sigilo das senhas de seus usuários é muito mais importante por causa da reutilização de senha em outros sites.
É definitivamente possível e, na verdade, você não precisa esperar por um site.
Dê uma olhada em SuperGenPass . É um bookmarklet.
Ele simplesmente reconhece campos de senhas, concatena o que você digita com o domínio do site, o transforma em hash, modifica um pouco de modo a obter apenas caracteres "admitidos" na senha e só então é enviada sua senha com hash.
Ao usar o domínio do site no processo, você obtém uma senha exclusiva por site, mesmo que sempre reutilize a mesma senha.
Não é extremamente seguro (base64-MD5), mas você distribui perfeitamente uma implementação baseada em sha-2 se desejar.
A única desvantagem é se o domínio for alterado. Nesse caso, você precisará pedir ao site para redefinir sua senha, pois não conseguirá recuperá-la por conta própria ... mas isso não acontece com frequência. considerá-lo um trade-off aceitável.
Eu gosto da resposta do X4u, mas na minha opinião algo como ele deve ser integrado ao navegador / à especificação html - como no momento em que é apenas metade da resposta.
Aqui está um problema que tenho como usuário - não tenho idéia se minha senha será criptografada na outra extremidade quando armazenada no banco de dados. As linhas entre mim e o servidor podem estar criptografadas, mas não tenho idéia do que acontece com a minha senha quando ela alcança o destino - ela pode ser armazenada como texto simples. O administrador do banco de dados pode acabar vendendo o banco de dados e, antes que você perceba, o mundo inteiro sabe sua senha.
A maioria dos usuários reutiliza senhas. Pessoas não técnicas porque não sabem nada melhor. Pessoas técnicas, porque uma vez que você chegar à 15ª senha, a maioria das pessoas não terá a menor chance de lembrá-las, a menos que as anotem (o que todos sabemos é também uma má ideia).
Se o Chrome ou IE ou qualquer outro item que eu estivesse usando poderia me dizer que uma caixa de senha será instantaneamente hashed no lado do cliente usando um servidor gerado e protegerá a senha em si - então eu saberia isso como usuário Eu poderia reutilizar uma senha com menos risco. Eu ainda quero os canais criptografados, assim como não quero que nenhum beiral caia durante a transmissão.
O usuário precisa saber que sua senha não está disponível para ser enviada ao servidor - apenas o hash. No momento, mesmo usando a solução da X4U, eles não têm como saber que esse é o caso, porque você não sabe se essa tecnologia está em uso.
Eu acho que é um bom método para usar ao construir algo como um framework, CMS, software de fórum, etc., onde você não controla os servidores nos quais ele pode ser instalado. Ou seja, SIM, você deve sempre recomendar o uso de SSL para logins e atividades registradas, mas alguns sites que usam seu framework / cms não o terão, então eles ainda podem se beneficiar disso.
Como outros apontaram, o benefício aqui NÃO é que um ataque MITM não possa permitir que outra pessoa faça login nesse site específico como você, mas sim que esse invasor não poderá usar o mesmo nome de usuário / senha combo para logar em possivelmente dezenas de outros sites em que você possa ter contas.
Esse esquema deve salgar com um sal aleatório ou uma combinação de sais específicos do site e específicos do nome de usuário, para que alguém que obtenha a senha não possa usá-lo para o mesmo nome de usuário em outros sites (mesmo sites usando o esquema de hash idêntico), nem contra outros usuários do site que possam ter a mesma senha.
Outros sugeriram que os usuários devem criar senhas exclusivas para cada site que usem ou usar gerenciadores de senhas. Embora isso seja um bom conselho em teoria, todos sabemos que isso é tolice confiar no mundo real. A porcentagem de usuários que fazem uma dessas ações é pequena e duvido que isso mude em breve.
Portanto, um hasher de senha javascript é o mínimo que um desenvolvedor framework / cms pode fazer para limitar o dano de alguém que está interceptando senhas em trânsito (o que é fácil em redes Wi-Fi atualmente) se o proprietário do site e os usuários finais estão sendo negligentes quanto à segurança (o que eles provavelmente são).