protocolo de início de sessão

Question

Como devo projetar um protocolo de início de sessão para ser mais seguro a maneira que eu tê-lo agora é

1. o cliente conecta e envia seu nome de usuário
   
2. o servidor envia o sal (sempre mesmo) para o usuário
   
3. o cliente acrescenta o sal com a senha hashes-lo e envia para o servidor
   

Desta forma, a senha está escondido o tempo todo, mas ele não parar um hacker apenas copiar o hash se ele pode vir sobre ele e enviá-lo depois que ele recived a senha ...

Answer 1

Deixe de segurança a um protocolo de nível superior (SSH, SSL) e manter a sua simples.

Answer 2

Se o servidor só aceita a senha salgados em uma conexão que originalmente desafiou com que o sal , em seguida, o hacker teria que manter a conexão até que ele tem o mesmo sal como o que ele viu o hash para. Eu não estou dizendo que isso é ideal (e um Diffie-Hellman seguido de autenticação totalmente criptografado pode ser mais seguro, embora ainda suscetível a um ataque man-in-the-middle a menos que você tiver cuidado), mas eu acho que simples ajuste seria pelo menos benéfico.

Então, novamente, eu não sou um especialista em segurança e você, sem dúvida, não deve seguir o conselho de segurança de quaisquer não-especialistas.

Answer 3

A segurança é difícil.

não rolar o seu próprio protocolo de início de sessão, use um existente comprovada uma ou fazer algo trivial e robusto ao longo de um (SSH, SSL ...) conexão criptografada. Há tantos robusta drop-in implementações de protocolos comprovados lá fora, e muitos exemplos de sistemas falhando devido a reinvenção falho de rodas -. Se o login está protegendo qualquer coisa de qualquer importância em tudo, simplesmente não há desculpa

Dito isso, se o seu objetivo aqui é aprender a projetar tais algoritmos, eu recomendo fortemente Bruce Schneier do " Applied Cryptography ".

Answer 4

Passo 2 parece ser a fraqueza maior, lá. Se você pode ter certeza de que o servidor envia um "suficientemente grande" sal e nunca o mesmo sal, duas vezes (eu suspeito que uma pequena porção de números aleatórios decentes, além de um contador de incremento, então hash pode ser suficiente, mas não posso provar que é), que provavelmente seria o suficiente. Como alternativa, seguir o exemplo de ssg e encapsular a coisa toda em uma sessão SSL.