Bonjour à tous,
 
Je suis en train de développer pour moi une petite application de backup, avec une partie logiciel client et un serveur. Même si c'est du travail que je fais à priori que pour moi, ça n'empeche pas que je veux faire du travail propre. De plus, j'ai l'intention d'en faire un freeware (ou autre license), si ça peut aider et/ou servir à qqu... (ça me ferait plaisir même que quelqu'un utilise ça )
 
Dans ma vision, le serveur de backup est une boite noire sur laquelle tourne l'application serveur.
Cette boite noire héberge une base de donnée d'accès uniquement locale.
Les mots de passes sont stockés en base mysql, base hébergée par le serveur.
On va imaginer le serveur blindé, personne à part l'administrateur n'a acces.
Donc personne ne peut venir lire la base SQL depuis l'extérieur.
 
Pour cette application, j'ai des users, qui ont des mots de passes  
J'ai un client pour faire la restauration, et un client pour faire le backup
Un gars qui connait sont mot de passe peut évidement utiliser les 2 clients.
Par contre, j'aimerais qu'un utilisateur puisse autoriser des backups automatiques depuis un client, sans avoir a être la pour rentrer son mot de passe.  
1ère solution :  
mettre le passe en clair sur la machine client => vu qu'à priori, ça peut être visible par  tout le monde => exclu
2ème solution  
mettre le mot de passe en crypté sur la machine client => un peu mieux, mais le pb, c'est que on peut toujours récupérer le mot de passe crypté et aller le mettre sur un autre machine et/ou l'utiliser pour faire de la restauration.
 
Il faudrait donc utiliser, pour les clients de backup, des mots de passes qui sont spécifiques à chaque machine. Et on peut difficilement imposer à l'utilisateur de donner un mot de passe qui dépend d'une machine.  
 
Le but est de trouver un système assez robuste pour que même si quelque déssamble le client et le serveur, que ce quelqu'un soit capable de voir ce qui est censé passer entre les 2, et que ce quelqu'un soit capable de se faire un client sur mesure, il ne soit pas capable de faire quelque chose de mal à un serveur non hacké, hébergeant le vrai code.  Evidement, si le serveur est aussi hacké, ya plus de soucis ...  
 
J'ai donc pensé à un systeme, et j'aimerais vos critiques / idées / commentaires.
 
Pour un user de login "login" et de mot de passe "mdp"
 
Coté serveur, en base, le chiffrement stocké pour le mot de passe est  
md5_en_base = md5(login+"#"+longueur(login)+"#"+mdp)
 
j'introduit un "grain de sel" pour éviter le crack par utilisation de table précalculée
 
 
Utilisation en mode restauration  
=>  
l'utilisateur entre son login et son mot de passe dans le client de restauration.
Le client calcul le md5 comme ci-dessus, on l'envoie sur le serveur qui regarde si c'est bon.  
 
Utilisation en mode backup
=>
cas 1 : - L'utilisateur entre son login et son mot de passe dans le client de backup
On calcule une chaine "chaine_identification_client", qui sera déterminée par exemple en utilisant l'ip du client. cela permet d'avoir une chaine à priori unique par PC client. La chaine n'a rien de compliqué, elle peut même être publique.
 
On calcul  
temp = md5(login+"#"+longueur(login)+"#"+mdp+"#"+chaine_identification_client)
on envoit temp au serveur  
le serveur construit sa propre chaine_identification_client, toujours en se basant sur l'ip du client par exemple
le serveur prend le md5 en base pour le mot de passe, et le complète pour calculer  
temp' = md5_en_base updaté par chaine "chaine_identification_client"
Si temp=temp', alors le serveur est OK, on continue.  
 
cas 2 : - L'utilisateur veut permettre l'automatisation de l'execution de client de backup
On stocke sur le client la chaine cryptée temp calculée si dessus. Cette chaine peut être public
Quand on lance le soft client, il envoit directement au serveur temp .  
le serveur fait comme à l'étape précédente, il calcul temp' et vérifie l'égalite.
 
 
Intéret :  
le fait d'ajouter 'chaine_d'authentification_client' fait que même si le password cripté est en clair sur la machine, il ne peut pas être utilisé ailleurs.  
De plus, le fait de connaitre le mot de passe crypté pour le cas du client d'upload ne permet pas de connaitre le mot de passe crypté nécessaire pour le client de restauration, donc même en cas d'utilisation de client de restauration hacké "fait maison".
De plus, en cas d'utilisation d'un client hacké, vu que c'est le serveur qui fait les vérification, il sera dur de le berner.  
La seule limitation que je vois à l'heure actuelle, et je ne sais pas trop comment y remédier, c'est un cas de vol d'ip ...  
 
Pour ceux qui ont eu la patience de lire, que pensez-vous du system ?  
 
- L'utilisation du md5 comme fonction de cryptage vous semble correte ?  
- Je me base dans mon idée sur une hypothèse, donc je ne connais pas du tout la véracité :
 
si on connais md5(ab), et b, peut-on retrouver (par calcul simple ou brutforce de durée raisonnable) md5(a) ?  
(ab = chaine de caractères a et b concaténées)
 
je pense que c'est vraiment compliqué, même pour une chaine b de petite longueur, mais est-ce vraiment le cas ?
 
 
Merci pour vos avis

déja le md5 c'est pas du cryptage mais du hashage.
Ensuite, le md5 est aujourd'hui un peu dépassé. essaie plutot les fonctions de hashage type sha dont le domaine de colision est plus élevé que le md5.

Coucou Rémi,
 
3Phach4 a raison pour le md5, mais le sha ne résoud pas pour autant ta problématique
 
avec le md5 tu obtiens une chaine unique de 32 caractères à partir de la chaine que tu veux hasher. ca tu le sais.
Et cette chaine est toujours la même à partir de la même chaine source.
 
Le principe est que (théoriquement), on ne peut pas remonter à la chaine initiale à partir du hash généré.
 
A froid comme ça ce n'est pas évident de donner un avis/solution au problème
 
L'idée de stocker le hash du mdp sur le client n'est pas une mauvaise idée. seulement comme tu l'as judicieusement pensé, il faut ajouter un sel pour éviter le pb soit reporté au niveau de la chaine hashée qu'il suffirait alors de recopier.
 
Fonder le sel uniquement sur l'ip client n'est pas la solution à mon avis puisque l'ip est modifiable coté client et donc l'identité peut être usurpée.
Pourquoi ne pas fonder ce sel sur un autre composant matériel du poste client: adresse MAC, numero de serie du disque, etc... pour rendre la chaine d'identification dépendante du poste client?
Ainsi une etape de la validation de la chaine d'identification consisterait a vérifier les éléments matériels identifiants. Et la chaine copiée sur un autre poste ne serait pas utilisable, meme en changeant l'ip.
 
Maintenant en face d'un personne capable de décompiler et vraiment motivée ca sera dur voire impossible d'obtenir un système infaible.

 
3Phach4 => je mate le sha .. ça l'air pas mal. Je vais regarder du coté de jacksum.
Kaiser =>  
le pb c'est qu'en java, j'ai pas moyen de chopper autre chose coté serveur (enfin, à ma connaissance). j'ai pas trop moyen de récupérer la mac du pc ou je ne sais quoi d'autre. je suis obligé de faire confiance à ce que m'envoit le client sauf pour le hostname du client (c'est même pas l'ip en fait ).  
 
je crois que je vais lacher l'affaire. En tout cas, j'aurais appris quelque chose pour le sha.  
 

Si mes souvenir son bon, y a une methode de System qui renvoie un tas d'infos systemes. (version de l'os, memoire dispo, proc, etc...)
Y a peut etre des infos utilisables.
 
Sinon il doit quand même y avoir une methode qui te retourne l'ip du poste.