Discussion :

[aimer_Delphi]

Bonjour a tous ,
pour protéger mon application j'utilise le N° physique du disque dur (car ce dernier ne changera pas après le formatage du PC ) ,
et pour stocker cette information (le N° du disque dur) j'utilise une unité appelé EXEMOD ,
cette unité permet d’écrire dans le fichier exécutable de mon logiciel.
mais à ce que j'ai remarqué la plupart des développeur utilisent beaucoup plus la base de registre ou bien encore un fichier binaire.
d’après votre expérience quelle est la meilleure méthode a utiliser ?
Unité EXEMOD , Base de registre , fichier binaire.?
merci pour vos suggestions

[gbegreg]

Bonjour,

A titre personnel, je ne suis pas fan des systèmes de protection qui se basent sur des ID physiques : dans ton cas, si l'utilisateur change de disque dur suite à un crash disque par exemple, l'application ne fonctionne plus. De plus, écrire des informations dans l'exécutable lui même c'est prendre le risque que l'application soit bloquée par l'antivirus...

Ce qui me parait le plus simple, c'est par exemple un bête formulaire de saisie (nom, adresse mail par exemple) qui s'adresse à un site web. Du site, une clé est générée et renvoyée à l'application. L'application stocke les informations "nom", "adresse mail" dans un fichier (texte ou binaire). Ensuite, lorsque l'application se lance, elle contrôle via l'algo de décryptage que la clé inscrite dans le fichier correspond bien au nom et adresse mail présents eux aussi dans le fichier. Ainsi, si l'utilisateur change un composant de son ordi ou change carrément d'ordi, sa licence reste valide.

[der§en]

Quand un client me demande de mémoriser une clef pour ces utilisateurs, je me tourne vers la stéganographie

[franckcl]

Une autre solution consiste à utiliser l'adresse MAC de la carte réseau.
Mais attention a ne pas lire les informations de la carte wifi car cela pose problème si le wifi est déconnecté. Donc bien lire la première carte Ethernet physique.
On change moins souvent de carte Ethernet que de disque dur..

Franck

[ApproxDev]

Bonjour,

Ce qui me parait le plus simple, c'est par exemple un bête formulaire de saisie (nom, adresse mail par exemple) qui s'adresse à un site web. Du site, une clé est générée et renvoyée à l'application. L'application stocke les informations "nom", "adresse mail" dans un fichier (texte ou binaire). Ensuite, lorsque l'application se lance, elle contrôle via l'algo de décryptage que la clé inscrite dans le fichier correspond bien au nom et adresse mail présents eux aussi dans le fichier. Ainsi, si l'utilisateur change un composant de son ordi ou change carrément d'ordi, sa licence reste valide.

Je n'ai pas tout compris. Vous renseignez le nom, l'adresse mail par exemple. Le site génère une clé dans un fichier sur le¨PC du Client. Il copie ce fichier et votre exécutable sur un autre appareil. Qu'est-ce qui empêche cette nouvelle utilisation si vous ne faites référence à aucun élément du PC (y compris dans votre cryptage de clé) La date de modification (de recopiage) du fichier de protection ? Autre chose ?

Cordialement. AD.

[foetus]

Je pense plutôt à ceci

Tu as un fichier (ou une base de données) sur un serveur (avec une forte probabilité qu'il soit accessible avec un identifiant/ mot de passe)

Et lors du premier lancement, l'application détecte qu'elle n'a pas de clef. Alors avec les informations saisies avec un écran formulaire, elle va interroger le serveur pour récupérer cette clef.
Si le serveur répond oui avec le clef, l'application sera débloquée.
Sinon, l'application affichera un message "No granted" or "Licence denied"

Évidemment le formulaire HTML pour ajouter une clef sur le serveur doit être pour un administrateur

[gbegreg]

Bonjour,
Je n'ai pas tout compris. Vous renseignez le nom, l'adresse mail par exemple. Le site génère une clé dans un fichier sur le¨PC du Client. Il copie ce fichier et votre exécutable sur un autre appareil. Qu'est-ce qui empêche cette nouvelle utilisation si vous ne faites référence à aucun élément du PC (y compris dans votre cryptage de clé) La date de modification (de recopiage) du fichier de protection ? Autre chose ?
Cordialement. AD.

La solution proposée par foetus est possible si l'application est installée sur une machine ayant accès à Internet.

Dans la solution que je propose, c'est le client qui accède à un formulaire web de l'éditeur de l'application : il fournit diverses informations (mail, nom du client...) et valide. La page web génère à partir des infos une clé et l'affiche en retour. Le client renseigne cette clé dans un fichier de paramétrage de l'application (une une boite de dialogue spécifique de l'application). L'application dispose de l'algo de décryptage de la clé et au démarrage va décoder la clé et contrôlée si elle est bonne.
On peut mettre les informations que l'on souhaite dans les informations qui vont permettre de générer la clé. J'indiquais les nom et mail mais on peut mettre ce qu'on veut (exemples : des dates de validité de la clé, la valeur de la variable d'environnement COMPUTERNAME si on le souhaite...). Si on prend par exemple la variable COMPUTERNAME, l'application le décodera de la clé et le contrôlera lors de son lancement...
=> les avantages sont que l'application elle même n'a pas besoin d'avoir accès à Internet (certains serveurs sont peuvent être sensibles et n'ont pas accès au web) et qu'il n'y a pas de lien trop fort avec le hardware (pour limiter les risques de blocage de l'application en cas de changement de composant)

Ce n'est que mon avis mais mon expérience me fait penser qu'il faut trouver une solution qui ne soit pas (trop) contraignante pour le client (si le disque dur ou la carte mère sont changés et que le client doit redemander une clé pour continuer à utiliser l'application c'est contraignant car évidemment, le client en aura besoin de manière urgente). Si on met des contraintes importantes pour maximiser la protection de l'application, il faut avoir un service de support bien taillé pour répondre aux sollicitations et ce rapidement...

[foetus]

il me semble qu'il manque un truc important dans ta procédure

Lorsque tu dis "le client qui accède à un formulaire web de l'éditeur de l'application", ici, le client va recevoir un lien temporaire avec une date d'expiration

Parce que sinon , c'est le client qui génère la clef, c'est le client qui donne les infos, c'est le client qui installe la clef, c'est le client qui décode/ valide la clef avec les infos qu'il a saisi.

C'est le client qui fait tout, et il n'y a pas de contraintes/ périmètres/ limites/ ...

[gbegreg]

c'est le client qui génère la clef,

Non c'est le site Web qui génère la clé.

c'est le client qui donne les infos, qui installe la clef

Oui.

c'est le client qui décode/ valide la clef avec les infos qu'il a saisi

Non, c'est l'application qui fait automatiquement le contrôle.

Exemple Delphi : on reçoit la clé par mail et c'est à l'utilisateur de la renseigner. Il y a plein d'autres solutions qui ont un mécanisme similaire. Si l'application est installée sur un poste ayant accès à internet, l'application peut également avoir son propre formulaire pour contacter le service web de génération de clé à partir d'informations saisies par l'utilisateur et/ou récupérées par l'appli (exemple : COMPUTERNAME). En retour, elle enregistre la clé dans son paramétrage. L’utilisateur n'a plus qu'à fournir certaines infos.
Si l'application n'a pas accès à internet, le client devra installer la clé.

NB : ce n'est qu'une proposition, chacun est libre de faire comme il veut
Moi ce qui me dérange le plus dans les systèmes de protection, c'est d'avoir un lien fort avec un composant : le jour où on change de composant il faut recontacter l'éditeur pour avoir une nouvelle clé (échange qui peut prendre du temps) et cela tombe évidemment à une période où on a besoin urgent de l'application... De grands éditeurs qui utilisaient des solutions liées à des composants techniques, utilisent maintenant d'autres solutions moins attachées au hardware. Autre point à prendre en compte, avec la virtualisation, l'application peut être installée dans une VM et celle ci peut changer de machine hôte...

[foetus]

Je réponds juste pour la stupidité des situations (mon côté )

Non c'est le site Web qui génère la clé.

Cool Internet qui est quelque chose qui n'existe pas va générer des clefs comme cela.

Donc "C'est suite à la saisie d'informations par l'utilisateur qu'une moulinette Internet PHP/ Javascript/ whatever va générer une clef et que l'utilisateur va la récupérer par email/ bouton "sauvegarder"/ whatever""

Non, c'est l'application qui fait automatiquement le contrôle.

Oui, mais c'est bien l'utilisateur qui lance l'application. Si rien ne lance l'application, je ne pense pas que l'application va se dire à un moment "tiens il faut que je valide une clef"

Delphi : on reçoit la clé par mail et c'est à l'utilisateur de la renseigner.

Donc cela sous-entend ce que tu as oublié de dire, ce que je souligne et ce que tu refuses à dire: "tu vas recevoir un lien temporaire avec date d'expiration qui va pointer vers un formulaire à remplir qui suite à ce dernier va te retourner/ envoyer une clef à installer à la main pour éviter de passer par Internet"


Mais bon tu disais que mon approche nécessitait que "l'application soit installée sur une machine ayant accès à Internet".
Or ce n'est pas forcément vrai au moins au premier lancement.
Mais ta solution nécessite aussi un premier accès Internet: donc c'est kif-kif-bourricot

[ApproxDev]

et un dongle ? Cela vaut une quarantaine d'euros. C'est utilisable sous Delphi... et même sous différents OS. C'est le fournisseur du dongle qui fournit les technologies d'encapsulement.

Cordialement. AD.

[gbegreg]

Oui, c'est bien l'utilisateur qui lance l'application. Si rien ne lance l'application, je ne pense pas que l'application va se dire à un moment "tiens il faut que je valide une clef"

L'application peut être un service démarré automatiquement au lancement de la machine...
Et puis "Si rien ne lance l'application", quel est l'intérêt d'avoir acquis l'application si on ne la lance jamais

Donc cela sous-entend ce que tu as oublié de dire et ce que je souligne et ce que tu refuse à dire: "tu vas recevoir un lien temporaire avec date d'expiration qui va pointer vers une formulaire à remplir qui suite à ce dernier va te retourner/ envoyer une clef à installer à la main pour éviter de passer par Internet"

Je ne refuse pas de le dire, mais je ne vois pas l'intérêt du côté temporaire de la chose. Le lien (vers le formulaire de génération de la clé) peut être permanent. Au moment de la validation, l'application web peut contrôler que le client a bien réglé la facture, le nombre de licences qu'il a demandé à générer (on lui laisse un certain nombre de génération (5 fois par an par exemple histoire qu'il puisse se débloquer en cas de situation urgente))...

Mais ta solution nécessite aussi un premier accès Internet: donc c'est kif-kif-bourricot

Oui, il faut un accès internet mais la différence c'est tu peux demander la génération de la clé depuis n'importe quel ordi ayant l'accès à internet et pas obligatoirement le poste/le serveur sur lequel est installé l'application.


Tu as raison : il y a une multitude de situations possibles. Mais en fonction de la criticité de l'application, il faut être assez souple : si le client a une marge de manœuvre et est autonome pour se sortir d'une situation bloquante je pense que cela peut être un plus pour la solution.

[Andnotor]

Cool Internet qui est quelque chose qui n'existe pas va générer des clefs comme cela.

Donc "C'est suite à la saisie d'informations par l'utilisateur qu'une moulinette Internet PHP/ Javascript/ whatever va générer une clef et que l'utilisateur va la récupérer par email/ bouton "sauvegarder"/ whatever""

C'est ça et ça ne pose aucun problème. C'est ce qu'on appelle un IPN (Instant Payment Notification) qui existe chez la plupart des revendeurs.
Le client achète sur un site marchand (ShareIt, Paypal, etc.), un dialogue s'instaure entre le serveur marchand et le tiens (contrôle de validité) et si tout est correct, ton serveur peut sans autre envoyer la clé par email.