Segurança, criptografia: Desafio estúpido - protocolo de resposta?
-
06-07-2019 - |
Pergunta
Ok guys apenas um pequeno jogo:
Eu tenho algumas especificações para um projeto. Em algum momento eles pedem o seguinte para criptografar uma senha por cima da rede, dizendo que é um protocolo de resposta de desafio:
CLIENT ----------------------------- SERVER (1)ask for challenge --------------> (2) <---------------------------- send SHA1 taken from the time (this is the challenge) (3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password (4) <---------------------------- Grant access
Para aqueles que não sabem disso SHA significa Secure Hash Algorithm, um algoritmo padrão para a criptografia.
Espero que seja claro. A pergunta é: Se eu capturar os pacotes 2 e 3 (o "desafio" e "password xor desafio", eu tenho a senha real apenas com outro xor entre ambos Existe outra maneira de implementar este tipo de protocolo!?!? ??
Solução
Como sobre o seguinte:
- O servidor envia um desafio aleatório
- O cliente envia SHA1 checksum (desafio + senha)
- Servidores compara contra a soma de verificação SHA1 (desafio + senha armazenada)
Outras dicas
Você seria capaz de fazer engenharia reversa a senha. Você deseja enviar o SHA da senha, não a senha em si. Rolar seus próprios protocolos de segurança quase nunca é uma boa idéia. você não pode usar SSL ou algo equivalente?
Isso é um protocolo muito horrível. Se isso é algo que alguém quer que você implementar, se recusam a. Há existentes, protocolos vetados para esse tipo de coisa. Se este é um jogo onde você apontar todas as falhas - Ok.
- Qualquer um que ouve os passos 2 e 3 conhece a senha
- Qualquer um que ouve o passo 3 e notas o tempo pode força-bruta a senha se ele tem alguma idéia da precisão do tempo no servidor
- eu posso fingir ser um servidor (envenenamento ARP, DNS rediction, etc), e obter sua senha, não concluir a etapa 4 e fingindo um tempo limite
- vulneráveis ??ao homem no meio ataques porque não há nenhum segredo compartilhado entre cliente / servidor ou certificados no servidor
- depende do servidor armazenando o SHA1 (tempo) e esperar por uma resposta, por isso pode sobrecarregar o servidor com pedidos de desafios e nunca respondeu.
E eu estou definitivamente faltando um pouco mais.
Você está certo - se você capturar o (senha XOR desafio) desafio e, em seguida, extrair a senha é fácil
.Você precisa usar a criptografia adequada no passo 3, não XOR. Criptografar o desafio com a senha.
Para tornar a vida de um atacante mais difícil que você pode adicionar dados aleatórios para o que você criptografar a: por exemplo, paddingCHALLENGEpadding criptografar. O servidor não importa o que o preenchimento é, ele sabe para onde olhar para o desafio, mas isso significa que um atacante não vai saber o que todo o texto simples é.
Como os outros já apontaram, você está correto. Também tenha em mente que alguém poderia interceptar a comunicação (3) e, potencialmente, reenviá-la enquanto o usuário real está experimentando problemas de rede (por exemplo: a DDOS), o impostor, então, estar conectado e que muitas vezes é suficiente para mudar a senha (ou seja , muitos sistemas não requerem que você fornecer uma senha para agradar a alterá-lo uma vez que você está logado).
Você pode querer considerar HMAC (hash com chave-Message Authentication Code). Eu tenho um blog sobre isso em detalhes aqui: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html e eu vou dar um breve resumo abaixo.
HMAC é um método de garantir que uma mensagem foi gerado por alguém com acesso a um segredo compartilhado. HMAC faz uso de algum tipo de função hash one-way (como MD5 ou SHA-1) para criptografar o segredo junto com uma mensagem. Isso gera um curto resumo de 16-20 bytes que age como uma impressão digital da combinação secreta mensagem +. Quando o resumo é enviado junto com a mensagem, o receptor (o nosso servidor) pode voltar a gerar o hash com o mesmo cálculo HMAC e comparar o gerada localmente digerir com o resumo que veio junto com a mensagem. Lembre-se: o servidor tem o segredo também, para que ele tenha informações suficientes para confirmar o resumo. (Isso só considera o problema de verificar a origem de uma mensagem, mas você pode usar a mesma abordagem para criptografar a mensagem inteira, se você usar um segredo diferente, digamos, um conjunto de chaves públicas).
A forma como eu iria fazer isso é o seguinte:
- Desafio do servidor.
-
responde Server com ele é a chave pública (Para, por exemplo criptografia RSA) digitalmente assinado.
-
verifica cliente PK, e criptografa senha com a chave, em seguida, assina digitalmente o criptografado senha.
-
verifica Servidor assinatura e decifra a senha para armazenar / verificá-lo.
A assinatura digital é importante aqui, pois funciona como o início de impedir o homem no meio ataques.
Como os outros têm para fora pontas, sim, este é um algoritmo de resposta de desafio pobres.
Você provavelmente querer verificar para fora Autenticação Digest , como o usado por HTTP. Na verdade, se o seu protocolo é sobre HTTP, você pode pular escrever seu próprio e apenas uso ou implementar isso.
criptografia de chave pública? Use a chave pública do servidor para criptografar a senha.
Embora nunca é uma boa solução para a implantação de seu próprio protocolo criptográfico, e é algo que eu não iria sugerir ....
Para superar o problema que você está enfrentando ... F - Uma função que leva a senha e um pseudo valor monótona crescente e retorna um número. Por exemplo Hash (Hash (Password) ^ Timestamp)
- Servidor: Peça Desafio, Enviar (Timestamp). Lembre-se Última Timestamp enviada.
- Cliente, envie Response (Enviar F (senha, Timestamp) e Timestamp)
- Servidor: Cheque Cliente usando Hash (Password) e Timestamp enviado pelo cliente (> Timestamp enviado Challenge) .
- Se o cliente estiver correta, conceder acesso.
- Certifique-se presente timestamp é maior do que todos cliente enviou timestamps antes do próximo desafio para evitar ataques de repetição.
Atenciosamente, Ashish Sharma
Eu acredito que o Diffie-Hellman é um protocolo de troca de chaves bem conhecido e sólida?