Por que quase nenhuma página da web possui senhas de hash no cliente antes de enviá-las (e hash-as novamente no servidor), para "proteger" contra a reutilização de senhas?

46

Existem muitos sites na Internet que exigem informações de login, e a única maneira de se proteger contra a reutilização de senhas é a "promessa" de que as senhas sejam colocadas em hash no servidor, o que nem sempre é verdade.

Então, eu me pergunto, quão difícil é criar uma página da Web que faça hash de senhas no computador cliente (com Javascript), antes de enviá-las ao servidor, onde elas seriam re-hash? Em teoria, isso não oferece nenhuma segurança extra, mas, na prática, isso pode ser usado para proteger contra "sites não autorizados" que não hash sua senha no servidor.

— Martín Fixman
fonte

18

um hash de senha enviada em claro não melhor do que uma senha enviada em claro é se o servidor está apenas comparando hashes, o homem no meio ataques amo este tipo de "segurança"

3

A melhor solução é (imo) um gerenciador de senhas do lado do cliente. Dessa forma, você pode gerar uma sequência aleatória de caracteres como sua senha e não depende do servidor para 'protegê-lo'.

— 22611 Dean Harding

2

@ Jarrod - parece-me, no entanto, que diferentes sites usando algoritmos de hash do lado do cliente impediriam o ataque descrito por esse quadrinho. Uma senha amplamente reutilizada torna-se muitas senhas diferentes através desses algoritmos de hash diferentes. Esse cálculo de hash do lado do cliente não impede que outros tipos de segurança sejam aplicados - como enviar o hash por uma conexão segura.

— 21311 Steve11

2

@ Steve314 meu argumento é que qualquer coisa no cliente é comprometida por padrão. Você pode hash e hash e hash, se estiver sendo feito no cliente e passado para o servidor clear, é apenas uma masturbação matemática nesse ponto. Eu tive que consertar um sistema que herdei, que foi projetado da maneira exata que você e o OP descrevem, sendo constantemente invadido por adolescentes com o Wireshark. Nós o bloqueamos apenas quando colocamos a REALcriptografia e criptografamos e assinamos todas as cargas de e para o servidor, a manipulação da conta parou e nunca mais aconteceu depois disso.

5

Parece que seu plano para se proteger contra sites não autorizados é pedir aos sites não autorizados que configurem uma segurança melhor. ?

— precisa saber é o seguinte

46

Por que não é usado? Porque é muito trabalho extra para ganho zero. Esse 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 adotar práticas menos seguras (como reutilização de senha, senhas de dicionário etc.).

— Rein Henrichs
fonte

2

Esta é a melhor resposta até agora.

1

É como criptografia Blu-Ray e DVD. Nem sequer requer uma chave para desbloquear. A única "proteção" fornecida era que, quando os DVDs foram lançados, custava mais comprar um disco para copiá-lo do que comprar uma cópia completa do filme. Claro que agora você pode comprar um dvd por um dólar e ainda mais é o fato de que as chaves são de conhecimento público agora. O mesmo está acontecendo com o Blu-Ray

— Michael Brown

2

Eu acho que hash uma senha do lado do cliente adiciona segurança. Se estou ouvindo, só consigo ver seu hash, não sua senha. Se o servidor enviar um desafio (como deveria), o hash nem será reutilizado.

— Andomar 14/06

2

Acho que a abordagem do x4u pode muito bem ser apropriada para alguns aplicativos em que os requisitos de segurança estão entre a transmissão de senhas no fio e o uso de certificados. Acho que alguns dos negativistas estão esquecendo que o hash da senha antes de ser ligada é feito além do tratamento padrão de credenciais no servidor. Portanto, a questão é a seguinte: a proposta do x4u melhora a segurança no cenário de transmissão de senha no fio ou não. Eu digo que sim. A chave para realizar isso está no uso de sais por senha.

— LOAS 23/07

6

A maneira correta de impedir ataques MITM é a criptografia de ponta a ponta. TLS (https) existe: use-o. Não invente seus próprios esquemas de criptografia.

— Rein Henrichs

14

Em teoria, isso não oferece nenhuma segurança extra, mas, na prática, isso pode ser usado para proteger contra "sites não autorizados" que não hash sua senha no servidor.

Como exatamente isso protege você? Parece que tudo o que você quer fazer é hash a senha com hash, o que é meio inútil. Porque a senha com hash se tornaria a senha.

Existem muitos sites na Internet que exigem informações de login, e a única maneira de se proteger contra a reutilização de senhas é a "promessa" de que as senhas sejam colocadas em hash no servidor, o que nem sempre é verdade.

Que tal não usar a mesma senha para mais de um site. Teoricamente, os sites que usam hash a senha são para impedir o acesso à sua conta, caso estejam comprometidos. Usar a mesma senha para vários sites é simplesmente estúpido.

Se você usou javascript, tudo o que o "hacker" precisa fazer é usar o mesmo método nas senhas com hash e hash. Depois de obter as informações do hash, é apenas o tempo necessário para calcular a senha -> o mesmo hash no banco de dados, o que impede o acesso a uma conta.

— Ramhound
fonte

1

Se o seu navegador sempre faz o hash da mesma maneira, sim, seu hash pode ser usado como senha em qualquer outro lugar. Mas e se os navegadores atribuíssem um salt com base no site (talvez o domínio?) Antes de fazer o hash e enviá-lo para o site? Eu acho que é uma ideia interessante.

— Tesserex 17/05

2

se estiver comprometido, qualquer sal do cliente estiver à vista, esta é uma pergunta ilógica. se você não entende a resposta de @ Ramhound, não deve escrever código que precisa ser seguro e começar a ler sobre segurança e criptografia desde o início.

3

Quando você está citando o cartaz original, formate o texto como tal (selecione o texto e use o ícone Citação pouco acima do editor)

— Marjan Venema

1

Jarrod, siga seus próprios conselhos e informe-se um pouco antes de fazer reivindicações ridículas. Um homem no ataque do meio é inútil contra funções seguras de hash com comprimento razoável de sal. E minha sugestão não é de forma alguma "segurança pela obscuridade", é realmente segura com base no que é atualmente conhecido e aceito pelos especialistas neste campo e é usada da mesma maneira em muitos protocolos. Não é minha invenção, eu apenas apliquei um procedimento bem compreendido no login de um site. Suas suposições falsas não ganham substância pelo fato de serem obviamente compartilhadas por muitas outras também.

— x4u 17/05

3

Se o salt é conhecido pelo cliente e é enviado de forma clara a partir de um servidor, qualquer coisa no meio também o conhece. Nunca disse, eu precisava desfazer o hash, se você conhece o sal no cliente, então não é seguro.

11

Porque isso agregaria pouco ou nenhum valor. O motivo do hash é que, se o seu banco de dados for invadido, o hacker não terá uma lista de senhas válidas, apenas hashes. Portanto, eles não poderiam se passar por nenhum usuário. Seu sistema não tem conhecimento da senha.

Seguro vem de certificados SSL, além de alguma forma de autenticação. Desejo que meus usuários forneçam uma senha para que eu possa calcular o hash dela.

Além disso, o algoritmo de hash 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 referenciados ocultos.

— Jon Raynor
fonte

3

Esta é a melhor resposta. Você deve criptografar na camada de transporte. Sem fazer isso, o resto não é seguro. Sim, você pode escrever uma função de criptografia ... mas essa função seria visível para os usuários finais (maliciosos). Use SSL.

— precisa saber é o seguinte

A segurança de um algoritmo de hash não deve depender de segredo. Os algoritmos de hash para segurança devem ser funções de mão única: mesmo se você tiver o código, é difícil desfazê-lo. Pelo contrário, você deve usar uma biblioteca de hash conhecida projetada apenas para senhas. Se não é bem conhecido, é quase certamente de buggy ou mal utilizado.

— leewz

6

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 aperto de mão usando meu certificado de cliente e o certificado do servidor.

Nenhuma senha é trocada e, mesmo que alguém hackear 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 do cliente pode ser armazenado em um cartão inteligente (e carregado em um cofre online seguro usando uma senha mestra).

A beleza de tudo isso é que ele remove o conceito de phishing ... você nunca digita uma senha em um site, apenas aperta as mãos com esse site. Tudo o que eles recebem é a 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 funcionaria apenas uma vez em um único site.

A Microsoft tentou fornecer algo assim no Windows com o Cardspace e posteriormente o enviou como um padrão aberto. OAuth é um pouco semelhante, mas depende de uma "parte emissora" intermediada. Os InfoCards, por outro lado, podem ser emitidos automaticamente. Essa é a solução real para o problema da senha ... removendo completamente as senhas.

OAuth é um passo na direção certa.

— Michael Brown
fonte

5

Embora os certificados de cliente sejam uma abordagem razoável para alguns casos de uso, eles não podem ser adicionados facilmente ao login de um site. Eles exigem muita cooperação dos usuários e dependem da segurança da chave privada dos usuários. O uso de uma chave privada pode ser seguro ou conveniente, mas não os dois ao mesmo tempo.

— X4u 17/05/11

5

a maioria das respostas aqui parece não entender completamente o ponto do hash de senha do lado do cliente.

o objetivo não é proteger o acesso ao servidor no qual você está efetuando login, pois a interceptação de um hash não é mais segura do que a interceptação de uma senha de texto sem formatação.

o objetivo é realmente proteger a senha do usuário , o que geralmente é muito mais valioso do que o acesso individual ao login do site, já que a maioria dos usuários reutiliza sua senha em vários sites (eles não deveriam, mas a realidade é que eles fazem isso, não deve ser descartado) )

O ssl é ótimo para proteção contra ataques mitm, mas se um aplicativo de login for comprometido no servidor, o ssl não protegerá seus usuários. se alguém obteve acesso malicioso a um servidor da Web, provavelmente será capaz de interceptar senhas em texto sem formatação porque, na maioria dos casos, as senhas são apenas hash por um script no servidor. o invasor pode tentar essas senhas em outros sites (geralmente mais valiosos) usando nomes de usuário semelhantes.

segurança é defesa profunda e o hash 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 devido à reutilização de senhas em outros sites.

— crocante
fonte

2

A resposta aceita compartilha muito bem seu ponto de vista. Mesmo que "a maioria das respostas" não o faça e porque sua resposta realmente não agrega muito valor, não faz sentido ressuscitar esta pergunta.

— Frank

provavelmente é mais um comentário do que uma resposta (desculpas por não descobrir como adicionar ao segmento de comentário da resposta aceita) e, mesmo que meu ponto seja compartilhado na resposta aceita, aparentemente não ficou claro o suficiente, pois as respostas parecem para escová-lo ainda. Obrigado pelo feedback

— crutchy

@Frank a resposta aceita limites por ser muito longo para incomodar a leitura. ele mostra muitos detalhes de como isso pode ser implementado e reflete sobre os benefícios no final. Ter um TL; DR em uma resposta diferente é benéfico.

— Jules

2

@Jules: É por isso que a edição existe.

— Robert Harvey

1

@JarrodRoberson Acho que você não está mais confuso com inseguro ? Se o MITM acontecer, o acesso ao site já será liberado, não é? A menos que você use certificado de cliente em vez de senha, o que seria muito complexo para usuários comuns. Do meu ponto de vista, o hash do lado do cliente evita que a mesma senha seja comprometida em outros sites, assumindo que cada algoritmo de hash seja único. Pode não ser mais seguro, mas também não é menos seguro? Então, por que você se esforça tanto nisso? Me deparei com isso a partir da meta, e esta é a melhor resposta que vejo até agora.

— ZypA13510 19/0918

1

Definitivamente, é possível e, na verdade, você não precisa esperar por um site.

Dê uma olhada no SuperGenPass . É um bookmarklet.

Ele simplesmente reconhece os campos de senhas, concatena o que você digita com o domínio do site, mistura-o, manipula-o de maneira a obter apenas caracteres "admitidos" na senha e somente então sua senha-hash é enviada por fio.

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 é que, se o domínio mudar, nesse caso, você precisará solicitar ao site que redefina sua senha, porque não conseguirá recuperá-la por conta própria ... embora isso não ocorra com frequência, por isso considero uma trade-off aceitável.

— Matthieu M.
fonte

Era isso que eu pensava quando li a pergunta; é praticamente inútil para sites fazerem seu próprio hash no cliente, mas uma extensão de navegador que faz isso (usando um pouco de sal com base no domínio) anula efetivamente os riscos associados à reutilização de senha. Claro, a parte divertida vem quando você tenta entrar a partir de outra máquina ...

— Aaronaught

3

isso não é mais seguro do que qualquer outro esquema que transmita a senha de forma clara. Torna a senha exclusiva, mas ainda não está criptografada , mas se eu tiver um servidor no meio, posso simplesmente pegar a senha complicada, mas ainda limpa, e usá-la o quanto quiser, não está mudando. Um hash não é uma bala mágica, nem sequer é criptografia, eles são chamados de hashes criptográficos, mas isso não significa que eles são criptografia. Não importa se minha senha é passworde / ou um SHA-256 passwordcom algum sal que é conhecido pelo cliente, um homem no meio do anexo pode capturá-la.

@ Jarrod Roberson: você pode usar a senha, é claro, mas não pode reutilizá-la para outra de minhas contas, que é o ponto. Portanto, se um dos sites que eu conecto tiver roubado sua base de senhas e eles forem armazenados de forma clara, minhas outras contas estarão seguras.

— Matthieu M.

@Aaronaught: é aí que brilha, na verdade. Como a senha enviada é derivada exclusivamente do domínio do site em que você faz logon e da senha mestre de sua escolha, você pode fazer login em qualquer computador (e navegador), desde que possua o bookmarklet. É por isso que é um pouco mais confortável que um certificado.

— Matthieu M.

6

@ Jarrod: Esta não é uma medida de segurança para o site , é uma medida de segurança para o usuário . Se todos usassem um esquema como esse, a reutilização de senha não seria um problema. Um esquema MITM pode usar a senha com hash do cliente para obter acesso a esse site, mas apenas a esse site. É aí que reside a melhoria. Normalmente, você espera ter acesso a muitas contas simplesmente quebrando uma senha, porque é provável que essa senha seja reutilizada; neste caso, a senha quebrada é praticamente garantida para ser válida apenas para o site ou banco de dados em que foi encontrado.

— Aaronaught

0

Gosto da resposta do X4u, mas, na minha opinião, algo como isso deve ser integrado ao navegador / à especificação html - pois, no momento, é apenas metade da resposta.

Aqui está um problema que tenho como usuário - não tenho idéia se minha senha será hash do outro lado quando armazenada no banco de dados. As linhas entre mim e o servidor podem muito bem ser criptografadas, mas não faço ideia do que acontece com a minha senha quando ela chega ao destino - ela pode ser armazenada como texto sem formatação. 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 conhecem melhor. Pessoas técnicas, porque quando você chega à 15ª senha, a maioria das pessoas não tem chance de se lembrar delas, a menos que as anotem (o que todos sabemos também é uma má idéia).

Se o Chrome ou o IE ou o que quer que estivesse usando pudesse me dizer que uma caixa de senha instantaneamente será hash do lado do cliente usando um sal gerado pelo servidor e efetivamente proteger a própria senha - então eu saberia que, como usuário, poderia reutilizar uma senha com menos risco. Eu ainda iria querer os canais criptografados, assim como não quero que nenhum beiral caísse durante a transmissão.

O usuário precisa saber que sua senha nem sequer 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 se esse é o caso, porque você não sabe se essa tecnologia está em uso.

— Chris Nevill
fonte

1

ele é integrado ao navegador, procure a autenticação digest e você verá as etapas repetidas no http para obter um hash de senha, com informações extras e verificado no servidor.

— Gbjbaanb

-1

Eu acho que é um bom método para usar ao criar algo como uma estrutura, CMS, software de fórum etc., onde você não controla os servidores nos quais ele pode estar instalado. Ou seja, SIM, você sempre deve recomendar o uso de SSL para logins e atividades de logon, mas alguns sites que usam o framework / cms não o possuem, portanto ainda podem se beneficiar com isso.

Como outros já apontaram, o benefício aqui NÃO é que um ataque MITM não permita que outra pessoa faça login neste site específico como você, mas sim que esse invasor não poderá usar o mesmo nome de usuário / senha para faça login em possivelmente dezenas de outros sites nos quais você possa ter contas.

Esse esquema deve usar um sal aleatório ou uma combinação de sais específicos de site e de usuário, para que alguém que obtenha a senha não possa usá-la 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 criassem senhas únicas para cada site que usassem ou usassem gerenciadores de senhas. Embora este seja um bom conselho em teoria, todos sabemos que é tolice confiar no mundo real. A porcentagem de usuários que fazem uma dessas coisas é pequena e duvido que isso mude em breve.

Portanto, um hasher de senha javascript é o mínimo que um desenvolvedor de framework / cms pode fazer para limitar o dano de alguém que intercepte senhas em trânsito (o que é fácil através de redes wifi hoje em dia) se o proprietário do site e os usuários finais estiverem sendo negligentes sobre segurança (o que provavelmente são).

— matthewv789
fonte