Protocole de connexion

Question

Comment devrais-je concevoir un protocole de connexion pour être plus sécurisé comme je l’ai en ce moment est

1. le client se connecte et envoie son nom d'utilisateur
   
2. le serveur envoie le sel (toujours le même) pour l'utilisateur
   
3. le client ajoute le sel au mot de passe le hache et l'envoie au serveur
   

De cette façon, le mot de passe est caché tout le temps mais cela n'empêche pas un pirate de copier le hachage s'il peut le récupérer et de l'envoyer après avoir reçu le mot de passe ...

Answer 1

Laissez la sécurité à un protocole de niveau supérieur (SSH, SSL) et gardez le vôtre simple.

Answer 2

Si le serveur accepte uniquement le mot de passe salted sur une connexion qui a initialement lancé un défi avec ce sel , le pirate informatique devra continuer à se connecter jusqu'à ce qu'il reçoive le même sel que celui pour lequel il a vu le hachage. Je ne dis pas que c'est idéal (et un échange de clé Diffie-Hellman suivi d'une authentification entièrement chiffrée est peut-être plus sécurisé, mais reste sujet à une attaque de type "man-in-the-middle" à moins que vous ne soyez prudent), mais je pense que un simple tweak serait au moins bénéfique.

Encore une fois, je ne suis pas un expert en sécurité et vous ne devriez sans doute pas prendre l'avis d'un non-expert en matière de sécurité.

Answer 3

La sécurité est difficile.

Ne lancez pas votre propre protocole de connexion, utilisez un un protocole éprouvé existant . ou faites quelque chose de trivial et de solide avec une connexion cryptée (SSH, SSL ...). Il existe de nombreuses implémentations robustes et instantanées de protocoles éprouvés, et de nombreux exemples de systèmes défaillants en raison d'une réinvention erronée des roues: si le nom de connexion protège quelque chose d'important, il n'y a aucune excuse.

Cela dit, si votre objectif est d’apprendre à concevoir de tels algorithmes, je vous recommande vivement l'option "a Cryptographie appliquée "..

Answer 4

L'étape 2 semble être la plus grande faiblesse, là-bas. Si vous pouvez vous assurer que le serveur envoie un message "suffisamment grand" sel et JAMAIS le même sel, deux fois (je soupçonne une petite portion de nombres aléatoires décents, plus un compteur incrémentant, puis haché peut suffire, mais je ne peux pas le prouver), cela suffirait probablement. Vous pouvez également suivre l'exemple de ssg et encapsuler le tout dans une session SSL.