Solution de clé de licence dans l'application Web, quelle est la meilleure approche?

14

Je suis déconcerté par une demande de mon manager. Je travaille pour une petite startup et nous avons développé une application web à tarif fixe avec un contrat de maintenance pour une BEAUCOUP plus grande entreprise. Connaissant des histoires d'horreur sur la façon dont les grandes entreprises ne paieront leurs factures qu'à la dernière seconde, nous avons décidé que nous aimerions nous protéger en étant en mesure de concéder sous licence cette application Web de manière à ce que si nous ne sommes pas payés, le logiciel ne fonctionne plus.

J'ai déjà vu cela pour des applications de bureau, mais ce sera une application Web qu'elles hébergeront en interne et ne seront pas accessibles depuis Internet.

Quelle est la meilleure approche pour ce faire, nous aimerions qu'elle ait une petite empreinte et souhaiterions pouvoir renouveler la clé de licence qu'ils ont distribuée.

Quelqu'un a-t-il fait quelque chose de similaire? Sommes-nous complètement fous? Quelqu'un a-t-il de meilleures suggestions?

web-development licensing web-applications

— maple_shaft
source

Pour faire cela correctement, vous aurez besoin de beaucoup de temps (ou ils vont juste le casser). Il est beaucoup moins cher d'acheter un produit conçu pour protéger les programmes Java. Sinon, faites simplement de la licence un extrait de code d'octet java que le programme lit et agit ensuite upton.

C'est ce que j'avais peur, je vais chercher des solutions tierces mais nous sommes déjà douloureusement surbudgétaires.

— maple_shaft

Ensuite, faites-le ralentir douloureusement 2 semaines après le paiement.

@ Thorbjørn, LOL !! ^ _ ^ Aussi tentant que cela puisse être, ce projet est un leader en perte pour essayer de générer des affaires supplémentaires avec cette société. La PLUS HAUTE QUALITÉ est de la PLUS IMPORTANTE. En même temps, nous ne voulons pas être complètement foutus pendant que nous recherchons le pot de miel.

— maple_shaft

@maple, sonne comme un mauvais plan d'affaires. Ensuite, laissez l'argent collecté aux comptables et n'envisagez pas de livrer des logiciels malveillants.

9

Il existe de nombreuses façons d'implémenter quelque chose comme ça, mais en voici une qui ne devrait pas être trop difficile à faire:

Vous avez besoin d'un site Web accessible au public quelque part qui héberge un fichier contenant les hachages des clés de licence qui ont été mises sur liste noire. La façon dont vous gérez ce fichier dépend de vous, mais le fichier lui-même n'a besoin que d'un hachage par ligne.

Ensuite, de manière récurrente, votre logiciel lance un téléchargement de ce fichier (la plupart des langues côté serveur le prévoient), puis le recherche pour le hachage de la clé de licence installée. S'il est trouvé, l'application sait qu'il doit mourir jusqu'à ce que la liste noire soit supprimée.

MD5 ou similaire plus un secret devraient être suffisants pour cela. Vous pourriez devenir plus sophistiqué et demander à l'application d'envoyer la demande à votre site et de la rechercher dans une base de données à la volée, mais le fichier (pour ce que je suppose serait une courte liste, espérons-le) resterait petit et pourrait être la manière la plus simple.

La partie la plus difficile sera de maintenir l'application morte. Après tout, vous devez stocker cela quelque part en interne, ce qui signifie que si cela est trop évident, il pourrait être facilement renversé, et même si ce n'est pas trop évident, il peut être facilement annulé en restaurant les tables appropriées / des dossiers). C'est pourquoi je suggère également une deuxième méthode de protection.

Cette méthode stockerait "LIVE" ou "DEAD" (ou quelque chose de suffisamment similaire) dans une table ou un fichier, mais encore HASHed. Cela doit être haché avec votre sel ET un horodatage. Chaque fois qu'une page de votre application s'exécute, vérifiez cette valeur avec une version hachée de "LIVE" + sel + horodatage, puis autorisez une plage valide d'horodatages (par exemple, un jour, deux jours, une semaine, un mois, etc. Gardez à l'esprit que plus la plage est large, plus les performances seront difficiles.). Tant que les choses correspondent (ou qu'une correspondance est trouvée), l'application est vivante; sinon, même si la valeur dans le fichier ou la table spéciale est "LIVE", elle sera toujours morte en cas de tentative de restauration à partir de la sauvegarde car l'horodatage tombera en dehors de votre seuil.

En résumé (cela suppose que vous avez une méthode programmatique pour vérifier la validité d'une clé de licence, telle qu'une sorte de somme de contrôle ou une autre méthode):

CheckBlacklist
- Convertir la clé de licence en hachage avec du sel
- Demander un fichier de liste noire au serveur
- Mon hachage est-il dans le fichier?
- Si OUI, stockez le hachage "DEAD" + sel + horodatage (tronqué au jour; pas besoin de stocker les heures + jours + minutes)
- Si NON, stockez le hachage "LIVE" + sel + horodatage (tronqué)
IsKeyAlive
- Créer un hachage à partir de "LIVE" + sel + horodatage tronqué
- Charger le hachage DeadAlive
- Sont-ils d'accord?
- Si OUI, alors nous sommes vivants; retourne VRAI.
- Si NON, alors nous sommes peut-être morts, mais nous pouvons toujours être dans notre fenêtre d'horodatage:
  - Soustrayez une journée de l'horodatage et répétez le hachage.
  - Sommes-nous d'accord maintenant?
  - OUI? Retour TRUE
  - Ajoutez une journée à l'horodatage et répétez le hachage
  - Sommes-nous d'accord maintenant?
  - OUI? Retour TRUE
- À ce stade, nous sommes hors de la plage d'horodatage sans correspondance. Retour FAUX. (Kill app)

Maintenant, Dieu sait qu'il y a un million et une façon dont cela peut échouer. Considérez toutes les manières possibles et construisez un système fiable (y compris celui qui suppose que le client a raison si le fichier de liste noire ne peut pas être téléchargé). Testez, testez, testez-le, puis testez-en plus avant de déployer, car si cela se passe mal, vous aurez perdu la confiance de votre client.

— Kerri Shotts
source

+1 Pour une réponse épique et compliquée O_o. Je me trompe peut-être, mais je ne pense pas que cela doive être assez compliqué. Je ne distribue pas Microsoft Office, c'est une application personnalisée pour un seul client. Les mêmes problèmes demeurent ici que le serveur hébergeant cette application peut ne pas être en mesure de communiquer avec un service externe. Je ne comprends pas pourquoi le chiffrement, les hachages et les sels sont vraiment nécessaires ici. Ce que nous voulons vraiment, c'est effectivement un kill switch.

— maple_shaft

Merci ;-) La raison pour laquelle je suggère d'utiliser un hachage est pour que personne qui renifle du trafic et / ou regarde du code / des tables / des fichiers chez votre client ne puisse dire ce qui se passe dans le monde. Les hachages ne signifient rien sans que les deux parties soient dedans, et le client est peu susceptible de comprendre que le hachage est en fait une représentation de leur clé de licence. (Si elle était transmise en clair, ils le sauraient immédiatement.) De même, cela réduit la nécessité de chiffrer ou de SSL sur votre fichier de liste noire - les hachages signifient eux-mêmes zip.

— Kerri Shotts

Remarque: si vous pensez que le client percevra qu'une restauration de certaines tables / fichiers est trop difficile, vous pouvez réduire considérablement la complexité en supprimant la vérification à chaque exécution de l'application. Cela dit, il ne faudrait pas trop de temps à quelqu'un pour comprendre ce qui se passe et trouver un moyen de le contourner.

— Kerri Shotts

1

CheckBlacklist: Et license-server.example.com: no route to hostmaintenant? Le serveur de licences n'existera peut-être même pas à l'avenir - et ne me dites pas que votre entreprise sera toujours en vie dans vingt ans, ce qui est plutôt improbable statistiquement.

— Piskvor a quitté le bâtiment

1

Il existe de nombreuses façons de contourner ce problème, notamment en n'utilisant pas vos propres serveurs. Utilisez Amazon ou Google ou quelque chose comme ça. Alternativement, intégrez la «confiance» à la vérification afin que si l'hôte est mort, les utilisateurs puissent continuer à utiliser l'application. Comme je l'ai mentionné dans l'article, il y a un million de façons dont cela peut échouer, et c'est vraiment pourquoi je suis contre ce genre de vérification. Je préfère faire confiance à mes clients que de proposer ce type de chèque. (Une clé de licence en soi, je vais y aller. Mais la mettre sur liste noire? Ça ne vaut pas la peine, OMI.)

— Kerri Shotts

4

Les autres réponses ont déjà fait du bon travail en couvrant le côté technique. Mais veuillez également considérer le côté juridique.

Avez-vous même le droit de bloquer leur application s'ils ne paient pas? Si vous ne l'avez pas mentionné d'avance dans le contrat, vous pourriez ne pas avoir le droit de le faire, même si les paiements expirent (comme vous n'êtes pas nécessairement en droit de reprendre possession de quelque chose que vous avez vendu). En outre, de nombreux pays ont des lois spéciales interdisant la "manipulation de programmes informatiques" - ce que vous faites pourrait être considéré comme tel et pourrait même vous exposer à une responsabilité pénale.

Je vous conseille donc d'en discuter d'abord avec un avocat, pour éviter de vous mettre dans l'eau chaude.

En fin de compte, il serait peut-être préférable de se fier uniquement au système juridique. S'ils ne paient pas, négocient et si cela n'aide pas, poursuivez. Dans de nombreux pays, poursuivre est relativement indolore et bon marché si la situation du contrat est claire (en Allemagne, par exemple, vous pouvez obtenir un Mahnbescheid pour moins de 20 €).

— sleske
source

Ce genre de liens dans la réponse à ma question de savoir si nous sommes fous. J'ai eu la nette impression que je n'ai pas le choix et c'est quelque chose sur quoi mes supérieurs insistent même si ce n'est pas dans le contrat. Malheureusement, je vis et travaille aux États-Unis, où vous ne pouvez pas engager une grande entreprise, même si vous avez raison. Ils ont des armées d'avocats qui enterreront tout dans la paperasse assez longtemps pour nous mettre à la porte s'ils le voulaient vraiment.

— maple_shaft

Je suis d'accord avec @sleske sur l'utilisation des canaux légaux. Assurez-vous que le contrat est solide, puis poursuivez-les s'ils violent les conditions. Ou du moins menacer de poursuivre. Dans ce que j'ai vu des grandes entreprises, elles sont très disposées à payer les vendeurs pour éviter d'être poursuivis ou d'enfreindre un contrat.

— RationalGeek

@maple_shaft: Aucune idée de la situation juridique aux États-Unis, mais j'espère que la situation juridique n'est pas aussi désespérée que vous la décrivez. Quoi qu'il en soit, si on vous demandait de mettre en œuvre cela, je soulignerais simplement les problèmes potentiels. Si vous obtenez toujours le feu vert (par écrit, bien sûr), vous avez fait tout ce que vous pouviez.

— sleske

Il n'y aurait aucun problème à avoir un système de licence à durée limitée où une fois la licence expirée, l'application est inutile. De nombreuses entreprises le font, grandes et petites - Adobe par exemple.

— James Snell

2

S'ils hébergent en interne, en quoi est-ce différent de tout autre logiciel que vous pourriez leur envoyer? Découvrez ce que vous feriez si vous expédiez, disons, une application d'affichage d'inventaire de bureau, et faites-le.

— David Thornley
source

Je suppose que je suis juste confus sur ce qu'il faut faire en général. J'imagine que l'application devrait faire une vérification nocturne de sa clé de licence en envoyant une demande à un serveur Web externe avec le numéro de licence. La réponse sera un succès ou un échec et sera stockée dans une variable de niveau de contexte d'application. L'application "s'éteindra" essentiellement si la clé de licence n'est pas valide. De cette façon, nous pouvons simplement "invalider" ce numéro de licence si nécessaire.

— maple_shaft

Pensez-vous que cette simple page d'authentification de licence doit être cryptée SSL? Même si quelqu'un devait implémenter un renifleur de paquets et pouvait dériver un numéro de licence valide, il aurait besoin d'avoir une copie distribuée de l'application pour que cela soit utile, et même dans ce cas, il est spécialement conçu. Je ne peux pas imaginer qu'il soit utile à quelqu'un d'autre que mon client direct.

— maple_shaft

1

Cela dépend du système. Avez-vous étendu un framework existant comme Magneto ou avez-vous écrit une application entière à partir de zéro? Si c'est la dernière, la construction d'une exigence de licence n'est pas trop difficile. Vous venez de livrer l'application avec une licence à court terme, une qui expire 45 jours après la facturation, puis vous en donnez une permanente plus tard.

Cela suppose que vous ne retournez pas également la source. :)

— Christopher Bibbs
source

Nous ne retournons pas la source. Nous contrôlerons le code source et distribuerons des versions régulières et des correctifs de bogues si nécessaire.

— maple_shaft

1

@maple_shaft: Eh bien, il y a toujours la possibilité de refuser de publier des correctifs ou des mises à jour tant que la facture n'a pas été payée, car je soupçonne que la maintenance est intégrée à l'achat initial ou vendue en continu, avec des dates de paiement régulières ( généralement, mais pas toujours, annuelle).

— Vatine

Pour assurer le suivi de @Vatine, pour les projets précédents qui manquaient de solides licences, nous avons utilisé les défauts comme point de levier pour extraire le paiement. Certains défauts peuvent ne pas être des accidents complets.

— Christopher Bibbs

@maple_shaft - Si vous n'avez qu'un seul client. La solution est simple. Ne fournissez pas de mises à jour dudit programme sauf si leur solde est de 0 $.

— Ramhound

1

Étant donné que le système est hébergé en interne, la plupart des solutions mentionnées ci-dessus impliquant la communication avec un serveur distant peuvent ne pas fonctionner.

Pourquoi ne pas inclure à la place un fichier de licence dans le projet qui inclut une date d'expiration. Une fois que l'horloge système dépasse la date d'expiration, le système cesse de fonctionner. Pour sécuriser le fichier, cryptez le contenu pour éviter toute falsification. Lorsque l'utilisateur paie ou renouvelle pour une année supplémentaire, vous lui envoyez un nouveau fichier de licence.

Notez que si vous utilisez PHP, le code est facilement disponible pour que l'utilisateur puisse le modifier, donc quel que soit le type de sécurité que vous mettez en place, l'utilisateur peut facilement le retirer et le supprimer. Si vous utilisez ASP.NET ou un autre langage compilé, ce n'est pas un problème car le code ne peut pas être modifié.

— Gavin Coates
source

C'est une bonne suggestion mais c'est une application Java packagée et déployée. Leur donner un nouveau fichier de licence signifie leur faire confiance pour l'insérer correctement dans le fichier WAR ou leur donner un tout nouveau fichier WAR qui serait gênant pour tout le monde. Ils ont des montagnes de paperasse et plusieurs informaticiens qui doivent justifier leur existence au sein de leur organisation en s'impliquant chaque fois qu'il y a une nouvelle version d'une application tierce. Je ne minimise pas votre suggestion simplement que ce pourrait être la suggestion la moins offensante.

— maple_shaft

Je suppose que même avec la plupart des langages compilés comme java, un pot peut être facilement compilé, mis à jour, recompilé et ensuite inclus dans la guerre, alors comment gérer cela?

— Sudarshan

1

(Divulgation - Je travaille pour Agilis Software, un fournisseur de systèmes de gestion de licence ).

La solution la plus efficace consiste à utiliser l' activation automatique du produit avec un bail de licence. Hors de la boîte, cela vous permet de:

Activez automatiquement la ou les licences du client. Au moment de l'activation, chaque instance est automatiquement verrouillée sur les paramètres choisis du système cible, et les limites de licence que vous définissez pour elles seront appliquées à votre application (par exemple, configuration des fonctionnalités, définition d'une limite d'essai ou d'abonnement).
Définissez un «intervalle de location», qui est la période de validité maximale de tout événement d'activation. Pour les clients dont le crédit est suspect, vous pouvez définir ce paramètre sur, disons, deux semaines, ce qui signifie que toutes les deux semaines, votre application se mettra automatiquement en "téléphone à la maison" en arrière-plan pour revalider la licence. S'ils sont en retard de paiement, vous pouvez désactiver leur licence sur le serveur hébergé et il cessera de fonctionner sur le prochain téléphone.
S'il n'y a pas de connexion réseau depuis le système cible, il y a un processus d'activation en libre-service de l'utilisateur via l'échange de fichiers cryptés sur n'importe quel terminal Web. Si votre utilisateur est dans cette position, vous souhaiterez peut-être allonger l'intervalle de location pour équilibrer les inconvénients pour eux avec votre besoin d'être payé. Une fois qu'ils ont payé, vous pouvez faire l'intervalle de location aussi longtemps que vous le souhaitez, jusqu'à perpétuel.

— Dominique
source