Discussion :

[youss20]

Salut

Ca me aprait pas mal, mais un gros trou : la clef AES stockée en clair chez le client. Autant ne pas crypter si tu fais ça

C'est justement pour avoir des remarques que j'ai fait ce post et je t'en remercie. Comment faire alors ? Si je chiffre le fichier avec une autre clé AES par exemple on tourne en rond. Quelle solution proposes-tu ?

[dingoth]

Faudrait juste penser à changer MD5 pour un algo plus fiable genre SHA256 ou mieux, qui n'ont pas encore de défaut connus.

[tchize_]

- Je crée un fichier "licence" avec l'id du client, l'adresse mac de son pc, la date de début et de fin de la licence.

C'est une méthode de vérification que, personellement, je n'apprécie pas trop d'un point de vue client. En effet, sur des grossse infrastructures comme des hopitaux, il est assez courant d'avoir un "parc" de machines à gérer, chacune étant interchangeable. Ainsi si ton client a pris un licence "15 postes" (imaginons hein), et si les machine sont basée, par exemple, sur du windows server, la technique habituelle en cas de défaillance d'une machine et de la remplacer immédiatement par une autre, en gardant les donnée (via le profil). Ainsi le downtime est réduit à quelques minutes et on a tout le loisir de réparer la machine. Dans ton cas, la nouvelle machine sera incapable d'exécuter le logiciel. Ce qui va fortement frustrer le client. De plus t'aura le même problème si le client fait un échange standard pour la carte.

- Concernant la date d'expiration, je sauvegarde la date courante à chaque exécution de l'application dans un fichier "dateExec" sur le pc du client. Ce fichier est chiffré à l'aide d'une clé AES (stockée aussi sur le pc du client). Je vérifie que cette date soit bien antérieure à la date courante pour éviter que le client triche en revenant à une date antérieure.

Je suis aussi pour le serveur NTP si t'en a la possiblité. N'oublie pas qu'il est peu probable qu'une clinique s'amuse à changer tous les jours l'heure des PC. On est pas sur des pc de méchants clients hackers Il faut garder en tête l'aspect productif de ce pc qui rendent mal aisées certaines bidoulles

Pour se connecter à la BD, les utilisateurs doivent entrer leur login et mdp. Les mdp sont hashés MD5 et stockés dans la BD.

J'ai aussi un fichier bd.conf contenant les données "en clair" pour se connecter à la BD. Je compte le crypter également avec une clé AES.

Pourquoi ne pas centraliser la base de donnée dans la clinique, ca te permettrais, au passage, d'en faire aussi un serveur controllant les licences


PS: t'as aussi le problème du fichier avec la licence publique que tu fournis chez le client. A priori, il lui suffit de remplacer ta clé publique par la sienne et il sera capable de générer ses propres fichiers de licence (pour autant qu'il arrive à en déterminer le format )


Je trouve, en ce qui me concerne, que le simple fait de mettre le nom du client, son adresse et les dates de validité dans le fichier de licence sont souvent suffisant. En effet, le fait que le "propriétaire" d'un fichier de licence soit identifiable facilement suffit généralement à éviter la dissémination de la clé et donc son usage abusif, le propriétaire ne voulant pas être taxable de piratage informatique ou non respect de la licence d'utilisation.


Une autre technique commerciale pour s'assurer que la clientèle paie effectivement et ne s'amuse pas à craquer les licences, c'est de ne pas les faire expirer, mais de garantir des mise à jour sur la période "payée". Ainsi, si ton logiciel coute X euros par an de licence, tu peux donner comme condition: licence à X euros, 1 an de mises à jour garanties. Prolongement de la licence possible annuellement pour X/2 euros, pour autant que le paiement n'aie pas été interrompu. Ainsi ,l'utilsiateur sera tenté de payer X/2 euros par an pour 3 mises à jour plutot que de courir le risque de devoir payer X euros pour 1 seule mise à jour (qui serait un achat neuf)

[youss20]

Faudrait juste penser à changer MD5 pour un algo plus fiable genre SHA256 ou mieux, qui n'ont pas encore de défaut connus.

Tu veux parler des mdp utilisateurs ?
Bonne idée je vais changer ça, merci

[youss20]

Voilà, j'ai commencé à faire les modifications suivant vos conseils.
Mais j'ai un petit problème avec le serveur NTP.
J'ai donc configuré mon serveur (192.168.1.5) comme serveur NTP, et la machine client se synchronise auto avec lui, pas de problème.

Là où ça bloque c'est quand j'ai inséré cette ligne dans mon code java.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Runtime.getRuntime().exec("cmd.exe net time \\192.168.1.5 /set /y");

Rien ne se passe, la machine client ne se sychronise pas avec le serveur.
Pourtant cette commande fonctionne très bien lorsque j'ouvre une fenêtre de commandes.

Une erreur de syntaxe java ?

[tchize_]

t'as probablement oublié de doubler tes \ dans les string java. De plus, je te déconseille de t'amuser a définir le temps sur la machine. Mieux vaudrais embarquer dans ton application java un client ntp qui se connecterais à ce serveur plutot d'essayer de définir le temps sur la machine local. Après tout, rien ne garanti que le user courant aie les droit pour changer l'heure.

[youss20]

t'as probablement oublié de doubler tes \ dans les string java. De plus, je te déconseille de t'amuser a définir le temps sur la machine. Mieux vaudrais embarquer dans ton application java un client ntp qui se connecterais à ce serveur plutot d'essayer de définir le temps sur la machine local. Après tout, rien ne garanti que le user courant aie les droit pour changer l'heure.

Très bonne idée en effet, merci
A présent je demande la date courante du serveur pour checker la licence.

[youss20]

C'est une méthode de vérification que, personellement, je n'apprécie pas trop d'un point de vue client. En effet, sur des grossse infrastructures comme des hopitaux, il est assez courant d'avoir un "parc" de machines à gérer, chacune étant interchangeable. Ainsi si ton client a pris un licence "15 postes" (imaginons hein), et si les machine sont basée, par exemple, sur du windows server, la technique habituelle en cas de défaillance d'une machine et de la remplacer immédiatement par une autre, en gardant les donnée (via le profil). Ainsi le downtime est réduit à quelques minutes et on a tout le loisir de réparer la machine. Dans ton cas, la nouvelle machine sera incapable d'exécuter le logiciel. Ce qui va fortement frustrer le client. De plus t'aura le même problème si le client fait un échange standard pour la carte.

Tu as tout à fait raison, c'est clair que j'enlèverai l'adresse MAC si je le vends dans le futur à des plus grandes boites.

Pourquoi ne pas centraliser la base de donnée dans la clinique, ca te permettrais, au passage, d'en faire aussi un serveur controllant les licences

C'était justement ma prochaine étape.
Donc au lieu de stocker le fichier contenant la clé publique RSA sur le pc du client, je le sauvegarde sur le seveur c'est bien ça ?

PS: t'as aussi le problème du fichier avec la licence publique que tu fournis chez le client. A priori, il lui suffit de remplacer ta clé publique par la sienne et il sera capable de générer ses propres fichiers de licence (pour autant qu'il arrive à en déterminer le format )

Et ce même sans la clé privée ???

[davidys]

Bonjour est il possible possible que vous me vendiez un code déjà près à l'emploi pour mon application développé sur netbeans 8.2