Como enviar a senha de forma segura via HTTP utilizando Javascript, na ausência de HTTPS?

Question

A questão muito básica todos os desenvolvedores enfrentam: sempre que o usuário envia o formulário, a senha é enviada através da rede e deve ser protegida. O site I desenvolver para não ter HTTPS. Nem o proprietário quer comprar um certificado SSL, nem está interessado em um auto-assinado. Então, eu quero proteger a senha enviada via HTTP utilizando Javascript ao enviar formulário.

Para downvoters ansiosos: Como enviar a senha de forma segura através de HTTP não dá qualquer solução sensata e estou em outra situação.

Se eu usar MD5, pode-se reverter essa seqüência de senha. E sobre nonce / HMAC? Qualquer biblioteca Javascript disponível para isso? Ou você tem qualquer sugestão / dica para enfrentar? Agradecemos antecipadamente!

Answer 1

Não há nenhuma maneira para enviar uma senha segura que o usuário pode verificar sem SSL.

Claro, você pode escrever algumas JavaScript que vai fazer uma senha segura para a transmissão over-the-fio através de hashing ou a chave de criptografia pública. Mas como pode o usuário ter certeza de que o próprio JavaScript não foi adulterado por um man-in-the-middle antes que chegou até eles, para enviar a senha para um atacante em vez do site, ou mesmo apenas comprometer a segurança do algoritmo? A única maneira seria para eles para ser programadores especializados e tê-los inspecionar cada linha de sua página e roteiro para garantir que ele foi kosher antes de digitar a senha. Isso não é um cenário realista.

Se você quer senhas para ser salvo de ataques man-in-the-middle, você deve comprar um certificado SSL. Não há outro caminho. Se acostumar com isso.

Se eu usar MD5, pode-se reverter essa seqüência de senha.

Não ... não trivialmente, pelo menos. Enquanto MD5 tem ataques contra ele, é um algoritmo de hash e, assim, unreversable. Você teria que força bruta-lo.

Mas, novamente, um atacante man-in-the-middle não precisa de olhar para os seus MD5s. Ele pode simplesmente sabotar o JavaScript você envia o usuário para fazer as MD5s.

Answer 2

A solução aqui é para não enviar a senha em tudo. Use desafio / resposta.

Na forma original incluem um grande bloco de texto aleatório juntamente com uma chave. Armazenar o texto original aleatória na sessão baseado em chave no servidor. Quando os submete cliente do formulário, use JS para hash de texto aleatório e senha juntos. Em seguida, enviar o nome de usuário, a chave eo hash texto aleatório para o servidor. NÃO enviar a senha. No servidor, use a chave para pesquisar o texto original aleatória, realizar a mesma operação de hash com a senha armazenada. Se o valor-servidor hash corresponde ao valor hash cliente, então você sabe que o cliente entrou a senha correta, sem nunca enviar a senha para o servidor.

Se a senha é certo ou não, expiram a chave e texto aleatório para cada um são one-time-uso.

Answer 3

Se você realmente quiser mergulho profundo para isso, olhar para o Diffie- Hellman troca de chaves que foi criado para "permitir que dois partidos que não têm nenhum conhecimento prévio do outro para estabelecer conjuntamente uma chave secreta compartilhada ao longo de um canal de comunicação inseguro"

Eu não sou um especialista em criptografia, então eu não sei totalmente se ele é realmente seguro se um atacante tem tanto o Cliente (código-fonte JavaScript) e o mecanismo de transporte (Packet sniffer)

Answer 4

Você pode usar uma implementação RSA javascript para criptografar a senha antes de enviar. (Aqui está um exemplo de RSA em JavaScript .)

Mas acredito tanto um presente e usando uma função hash será vulnerável a repetição ataques . Então, cuidado.

Answer 5

Infelizmente não haverá maneira de garantir a segurança de um pedido não-criptografada. Qualquer pessoa com acesso ao seu javascript vai simplesmente ser capaz de fazer engenharia reversa / adulteração com ele e qualquer pessoa com um packet sniffer será capaz de ver o tráfego não criptografado. Estes dois factos juntos médios:

Sem SSL? Sem segurança.

Answer 6

Qualquer transmissão que você tem que estar em claro; isto é, sem SSL suas informações críticas serão expostos. Vale a pena discutir esse ponto com o site proprietário. Em outras palavras, é melhor tomar as medidas necessárias para fortalecer a sua transmissão de dados e SSL é um dos passos, baratos básicas que você pode tomar.

Answer 7

eu não acho que o problema aqui é a tecnologia, mas como você explica a importância de SSL. Fornecê-los com materiais de leitura de confiança, tenho certeza que há uma abundância através da web.

Answer 8

A solução exige que o cliente seja capaz de criptografar a senha usando uma chave de criptografia secreta conhecida única para o cliente e do servidor.

SSL consegue isto requer o servidor eo navegador do cliente para ter seu próprio par de chaves pública assimétrica / privada, que eles usam para criptografar e transmitir uma chave de sessão aleatória entre eles. O resto da conversa, em seguida, usa essa chave de sessão seguro.

Então você está perguntando como resolver o mesmo problema, como SSL, sem o benefício de ter uma chave secreta que é conhecido única para o cliente eo servidor. Não sou especialista, mas parece que isso não pode ser feito, ou pelo menos não com facilidade.

Answer 9

Se você não tem acesso a SSL, MD5 devem ser suficientes para evitar a descoberta acidental de senhas (como em um arquivo de log de rede ou algo assim). Qualquer outra coisa seria um desperdício de tempo. Apenas certifique-se o aplicativo não dar acesso a informações sensíveis (ou seja, números de cartão de crédito, história médica, etc).

Tal como outros comentadores têm sugerido, um atacante sério será capaz de quebrar qualquer tipo de segurança na página. Mesmo SSL é uma pequena barreira desde a maioria dos usuários usar fácil de adivinhar senhas, re-utilizar as mesmas senhas em todos os lugares, vão dar a sua senha para qualquer um que pede, ou pode ser levado a desistir de sua senha por uma página copiada ou "tech apoio" telefonema.

Answer 10

- Inglês - Eu acho que em alguma coisa, mas eu não sei se isso poderia ser realmente seguro. Se você pode colocar o formulário em um arquivo php, então você pode criar um algoritmo para criar uma cadeia com base no tempo ou em outra coisa, e em seguida, colocar essa string em seu HTML.

Quando o usuário digite uma senha em um campo de entrada de senha, quando você depurar ele você canot ver o valor digitado pelo usuário, por isso antes de enviar as informações via POST ou GET, você pode usar a senha do usuário como uma dica para criptografar o string encriptada previosly gerado, e então, enviou-insted da senha digitada pelo usuário.

Desta forma, os atacantes não têm tudo dentro do código js, ??então eles vão precisar descobrir o algoritmo que você cria para decifrá-lo.

Esta é apenas uma idéia, por isso, se você pode me dizer como isso não pode ser seguro, eu aprecio isso.

- Espanhol - Se me acaba de ocurrir algo that puede servir, pero no se si Realmente mar algo seguro. Por medio de php puedes generar un algoritmo that cree un corda en base de al timestamp o algo más, y después Colocar ESTA cadena en el html.

Note that cuando alguien escribe una contraseña en senha tipo de entrada campo un, con un depuração no se puede ver el valor that tecleo el usuario (no se si Exista manera pero no quise Investigar más), Así que Podemos utilizar la contraseña that el usuario escribió Como palabra clave para encriptar la cadena de texto that previamente habiamos generado con php, POR medio de un algoritmo en JS. Sería algo asi como encriptar lo encriptado. Posteriormente lo que estariamos enviado não sería la contraseña tecleada, Si No esta ultima cadena Resultante.

Buscando un contra, eis Único Que se me ocurra es que el atacante Tendra that dedicarle mucho tiempo para TRATAR de encontrar el agoritmo that Creamos POR medio de php y poder decriptar la cadena final, o Tendra that hackear el Servidor para acceder al php y el obtener algoritmo.

Esto es ideia solo una, por lo que si pueden decirme Como esto puede sem seguro ser, se los agradeceria.

Answer 11

Como mencionado, nada disto é contra seguro servidor spoofing, como que requer uma capacidade de confiar no Javascript do lado do cliente. Mas se temos a certeza de que o servidor não pode ser falsificado (cert assinado, assinatura de hash imune ao comprimento de extensão, etc.), mas não que a conexão é imune a bisbilhoteiros, aqui está como eu' d implementá-lo.

Eu acho que a maneira mais segura é, em vez de armazenar H ( password ), onde H é a sua função hash de escolha, loja g ^ H ( password ), ou seja usar a senha como a chave privada para Diffie-Hellman. (Você também deve provavelmente usar um g aleatório para diferentes usuários, também - torna-se o seu sal.) Em seguida, para verificar, você gerar um nonce b, enviar o usuário g ^ b, e compute (g ^ H ( password )) ^ b. O usuário não precisa saber g - eles só precisam calcular (g ^ b) ^ H ( password ) = (g ^ H ( password )) ^ b. Agora você tem um número que ambas as partes sabem sse o usuário digitou a senha correta, e construindo um desafio-resposta à prova de conhecimento nulo baseado em saber o número correto é trivial, enquanto o número aleatório usado como "chave privada" do servidor faz com que o sistema imunitário abordagem para repetir ataques.