Protocole d'authentification d'un client auprès d'un serveur

Protocole d'authentification d'un client auprès d'un serveur - Algo - Programmation

Marsh Posté le 25-07-2005 à 11:30:32    

Je sais, dis comme ça c'est un peu basique [:itm]
 
En fait j'ai un serveur, j'ai un client.
Par nature, mon serveur doit envoyer des informations sensibles au client. Je dois donc absolument m'assurer que le client est une instance valable, non bidouillé.
 
Concrètement, je veux éviter qu'un gars cuisine lui même son client maison et puisse se connecter à mon serveur: je veux qu'il utilise MON client, que je distribue moi-même.
 
Par exemple, je suppose que Valve à implémenté qqchose de similaire pour authentifier chaque client Steam comme étant des vrais Steam pas trafiqués.
 
Si vous connaissez des solution, je suis preneur. Je demande pas du tout du code ni rien, juste des idées, des protocoles.
 
Merci d'avance :)
 
 
:hello:

Reply

Marsh Posté le 25-07-2005 à 11:30:32   

Reply

Marsh Posté le 25-07-2005 à 12:53:12    

Pour ce genre de probleme le RSA est parfait. De plus un truc con mais qui marche est d'envoyer le SHA du repertoire ou le client est installé (ou le SHA des fichiers importants par exemple), jusqu'a jour ou le gars le découvre ca marche au top.
Sinon j'ai entendu y a pas longtemps que les certificats sont des trucs bien puissant pour securiser des session ...


Message édité par Chronoklazm le 25-07-2005 à 13:19:31

---------------
Scheme is a programmable programming language ! I heard it through the grapevine !
Reply

Marsh Posté le 23-08-2005 à 21:32:58    

Hasher les principaux fichiers du client tq Chronoklazm le suggère et envoyer le resultat au serveur.
 
Pour éviter le rejeu, le serveur transmet au client un aléa qui vient initialiser la fonciton de hash.
 
Dans ton cas, je pense que c'est plutot l'authentification de l'utilisateur qui est importante plutot que l'aathentification du logiciel.... qui pourra tjs être hacké.
 

Reply

Marsh Posté le 24-08-2005 à 09:49:47    

xterminhate a écrit :

Hasher les principaux fichiers du client tq Chronoklazm le suggère et envoyer le resultat au serveur.
 
Pour éviter le rejeu, le serveur transmet au client un aléa qui vient initialiser la fonciton de hash.
 
Dans ton cas, je pense que c'est plutot l'authentification de l'utilisateur qui est importante plutot que l'aathentification du logiciel.... qui pourra tjs être hacké.


oui mais non. qu'est ce qui pourrait empêcher un client corrompu de faire un hash d'un client valide et de l'envoyer au serveur ?
 
je suis bien conscient que si l'utilisateur s'identifiait/authentifiait ça serit plus simple. Mais moi j'aime autant être user friendly et que le user ait pas à se prendre la tête à deux mains pour se souvenir de ses codes.

Reply

Marsh Posté le 24-08-2005 à 21:54:52    

Réponse : rien. C'est justement l'objet de ma dernière phrase. En outre l'authentification utilisateur peut être masquée par ton application cliente (mémorisation des données d'authentification utilisateur).
 
Il y a peut être d'autres voies à explorer... je pense par exemple à une application "cliente légère" qui serait fournie par le serveur à ouverture de session utilisateur (voire applet java et Cie).

Reply

Marsh Posté le 04-09-2005 à 12:38:08    

Salut, cette question m'interesse aussi.
Pour reprendre l'idée de xterminhate d'un client envoyé par le serveur (type applet) en quoi ça empeche une personne vilaine pas belle d'écrire son propre client et d'utiliser le meme protocole de commnication que le client "officiel" ? Surtout dans le cas d'une applet où le code source est presque lisible en clair (presque, je sais).
Une bonne idée est de crypter les données transmises, mais quelle méthode est la meilleure ?

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed