Principes de base de la sécurité de protocole à base de chaîne

Question

Je n'étais pas sûr de savoir comment formuler cette question, donc je m'excuse si c'est une copie d'autre chose. Je voulais vérifier la sécurité de mon application torsadée et penser que j'ai fait du bon travail, mais cela fait plus d'une décennie que j'ai écrit tout ce qui utilise des sockets crus ou gérés.

Transaction d'authentification: Le client se connecte et immédiatement une réponse de défi est renvoyée avec une chaîne hexadécimale de 16 caractères. Le côté client prend le nom d'utilisateur & mot de passe, le mot de passe est converti sha1 (salt + sha1 (mot de passe)) et les informations d'identification sont renvoyées au serveur en tant que {nom d'utilisateur, mot de passe}. Du côté serveur, l'authentification fait un modèle de recherche standard (si l'utilisateur existe et a un mot de passe égal à l'entrée, puis accorder).

Si la connexion entre l'utilisateur & client est perdue, la classe de protocole se marque comme sale et se déconnecte de l'objet utilisateur. À tout moment après ce point, pour avoir à nouveau accès à l'objet utilisateur, le client devra répéter le processus d'authentification avec un nouveau salt.

Ai-je raté quelque chose? Existe-t-il une approche meilleure/plus sécurisée pour un protocole basé sur un flux de caractères?

Answer 1

Le protocole que vous avez décrit concerne une attaque, c'est-à-dire l'attaque par rejeu. Cependant, vous êtes très vulnérable aux attaques MITM. La connexion TCP ne tombera pas lorsque l'attaquant se déplace sur le protocole. De plus, tout ce qui est transféré sur ce système peut être reniflé. Si vous êtes sur le réseau sans fil dans un café, tout le monde dans la région sera en mesure de renifler tout ce qui est transmis et puis MITM la session authentifiée. Un autre point est que sha1() est prouvé être non sécurisé, vous devriez utiliser sha256 pour tout ce qui touche à la sécurité.

NE JAMAIS RÉINVENTER LA ROUE, particulièrement quand il s'agit de sécurité.

Utilisez SSL! Tout le monde utilise SSL et il a une longue histoire de sécurité prouvée, et c'est quelque chose que vous ne pouvez pas construire. SSL Non seulement résolu Homme dans les attaques moyennes mais vous pouvez également utiliser des certificats au lieu de mots de passe pour authentifier à la fois le client et le serveur, ce qui vous immunise contre la force brute. Le soleil s'éteindra avant qu'un attaquant puisse forcer un certificat RSA 2048bit. Père plus vous n'avez pas à vous soucier d'un compte-gouttes de la veille reniflant la transmission. Gardez à l'esprit que OpenSSL est GRATUIT, générer des certificats est GRATUIT, et le chant des certificats est GRATUIT. Bien que la seule raison pour laquelle vous souhaitez signer un certificat est si vous souhaitez implémenter une PKI, ce qui n'est probablement pas nécessaire. Le client peut avoir codé en dur la clé publique du serveur pour vérifier la connexion. Le serveur pourrait avoir une base de données de clés publiques client. Ce système serait autonome et n'exigerait pas OCSP ou CRL ou toute autre partie d'une infrastructure à clé publique.

Answer 2

Votre authentification semble solide mais sujette à man in the middle attacks car elle ne garantit pas l'intégrité de la connexion au serveur.

Je suggère d'implémenter le protocole SRP 6 à la place. Il est prouvé pour être sécurisé, assure l'intégrité de la connexion et crée même un secret commun qui peut être utilisé pour établir un certain chiffrement symétrique de forme. Le protocole semble un peu difficile à première vue mais est en réalité assez facile à mettre en œuvre. Il y a aussi une démo JavaScript disponible sur le project website et des liens vers plusieurs implémentations dans différentes langues.