Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Crypter ou obfusquer les String dans les .class
Bonjour,
J'aimerais faire comme précisé dans le titre : crypter (obfusquer en fait) les chaînes de caractères dans mes .class.
Il semble exister plusieurs solutions pour faire du "String encryption" en .NET mais je n'ai rien trouvé pour le Java.
Connaissez-vous des méthodes, même basiques (disons que je ne vise pas un niveau de sécurité énorme).
Je précise que bien évidemment, je pars du principe que l'utilisateur décompile mes .class et s'amuse à regarder tout le code.
Merci !
salut,
tu peux te baser sur un chiffrement symétrique à base de RC4 (ou ARCFOUR).
L'algo de chiffrement / déchiffrement est très simple à implémenter et assez rapide dans son utilisation.
Je sais que le framework pulpcore en propose une implémentation (classe pulpcore.util.crypt.Arc4) dont tu peux t'inspirer.
Par contre:
- méthode bourrine: ça t'oblige à chiffrer une fois l'ensemble de tes Strings à la main et les copier/coller dans ton code.
- plus malin: tu te débrouilles pour regrouper toutes tes Strings dans un fichier unique qui sera transformé par ta moulinette directement pendant la phase de compilation via un appel de ta moulinette par Ant.
Par contre, il faudra de toute façon modifier chaque endroit de ton programme pour déchiffrer la string chiffrée avant son utilisation, à défaut d'avoir prévu la chose dès le départ.
Enfin, comme tu peux t'en douter, ce n'est pas le genre de "protection" qui tiendra bien longtemps pour quelqu'un d'un tant soit peu déterminé, étant donné que la clef pour déchiffrer les String sera probablement quelque part dans ton jar elle aussi.
Mais ça évite d'avoir immédiatement 'en clair' les Strings après avoir utilisé un décompilateur sur ton jar (voire après une simple lecture de tes .class dans un éditeur hexa).
etant donné que ce genre de chose est assez extrème pour un gain très marginal, j'aurai tendance à te dire d'éviter de gaspiller du temps avec ça. Si t'inciste pour le faire, toute l'api de java crypto est à ta disposition pour faire des encrypages/décryptage, mais va quand meme falloir coder une classe de décryptage et te tapper le changement de toutes tes strings.
Peux-tu préciser pour quelle raison tu en a besoin?
Merci, je vais étudier un peu vos propositions.
La raison : j'ai tout simplement un mot de passe (connexion à une BD) en clair dans mon code.
Je ne trouve pas de moyen de l'en sortir car de toute manière, l'utilisateur aura forcément accès au .jar ou .war.
En prenant du recul je peux comprendre que c'est un problème difficilement à résoudre : 100% de l'application est déployé chez l'utilisateur et je veux quand même masquer ce mot de passe (qui doit bien être stocké quelque part au final).
Mais étant donné le contexte, une "simple" obfuscation de chaîne (ou équivalent) suffirait.
d'un point de vue sécurité t'as un problème de design. Idéallement, il faudrait fournir un mot de passe par utilisateur. Avec autant d'accounts dans la base de donnée qui ont accès à tes tables. Ainsi, chaque user a son propre compte et il n'est pas nécessaire d'encoder le mot de passe dans l'application.
Partager un mot de passe hardcodé entre tous les user + application standalon c'est toujours un problème.
Pour ce qui est du .war, puisque tu le mentionne, dans ce derneir cas, je vois pas ou est le probleme, le war étant déployé sur un serveur, les securité du serveur devraient suffire à empecher aux personnes non autorisées l'accès au contenu du war et donc au mot de passe. Dans le cas d'une appli serveur, evidement, l'utilisation d'un mot de passe partagé est acceptable et normale
+1.Envoyé par tchize_
Même si tu es dans la situation où n'importe quel utilisateur 'public' doit faire des ajouts/modifs dans la base de données, passer par un 'intermédiaire' côté serveur me paraît plus pertinent.
Par exemple admettons que ton appli veuille ajouter une entrée dans une table 'x'. Au lieu d'aller directement tripoter la BdD et sa table x, elle va envoyer sa demande de modification à une page web (JSP, PHP, ...) qui -elle seule- contiendra les identifiants et l'accès à la BdD et ira faire la modif.
Ca ne coûte quasiment pas 'plus cher', et ça te permet:
- de limiter les actions à celles qui te sont nécessaires à ton appli.
- de garder les login/pass bien au chaud sur le serveur, de les renouveler quand bon te semble.
- d'ajouter (maintenant ou plus tard) un mécanisme de potection pour les utilisations frauduleuses (genre authentification par plage IP, anti-flood, etc...).
- de pouvoir modifier l'organisation interne de ta BdD à tout moment sans avoir à redéployer l'ensemble des clients, uniquement la/les page(s) web concernée(s) sont à modifier.
Je comprend bien tout ça, mais quand je parlais d'utilisateur, je voulais dire que l'application est déployée sur le serveur d'une entreprise et je voudrais que l'application (code mais surtout mots de passe) soit masquée de l'ensemble des personnes présentes dans l'entreprise et ayant accès à ce serveur Web/JEE.
Evidemment l'utilisateur final n'aura pas accès aux fichiers JSP, .class ou autre, mais les administrateurs du serveurs le pourront.
Cette application devrait pouvoir stocker localement (en gros dans le .war) des informations qui ne doivent pas être modifiées par, par exemple, le technicien ou l'admin serveur / BD.
Quelle que soit la méthode pour stocker ces informations (petite BD locale et privée à la SQLite ou H2, fichier texte/XML crypté, ...), il faudra un mot de passe ou une clé quelconque pour les protéger.
Et cette clé doit bien être connue de l'appli en elle-même quand elle va vouloir lire ces infos. D'où le mdp stocké quelque part.
Si je t'ai bien compris nouknouk, je fais déjà un peu ça : j'ai un seul fichier BD.class sur le serveur qui s'occupe de tout l'interfaçage avec JDBC / la BD, et donc qui stocke le mdp.
Ce fichier est donc décompilable pour en regarder les Strings à l'intérieur.
Désolé du semi-pavé et merci pour vos réponses. Je n'espère pas une solution magique, je sais que mes besoins et mes contraintes sont un peu bizarres, mais disons que je dois faire avec
.
Si tu ne fais pas confiance aux administrateur qui vont avoir accès au code de ton application, tu n'ira pas bien loin. Bien souvent le mot de passe est encodé en claire dans la configuration du serveur, sous forme d'informations relative à la configuration de l'un ou l'autre connection pool. C'est ensuite au administrateur à sécuriser l'accès à leur serveur. Par exemple en limitant les droit de lecture / écriture sur les fichiers de la webapp au user système qui va exécuter le conteneur J2EE. De plus, si tu déploie chez tes clients une application sur laquelle les client n'ont pas le droit de faire de la configuration lorsque, par exemple, il déplacent leur serveur de base de donnée ou changent les password, tu va avoir des clients furieux.
Ok.
Cette discussion confirme un peu ce que je pensais.
Il faut que je fasse suffisamment confiance aux utilisateurs et espérer qu'ils ne voudront pas à tout prix "hacker" l'application pour déverrouiller certaines sécurités.
Pour moi il y a déjà une belle étape de franchie entre "faire confiance à l'ensemble des utilisateurs du client Java" et "faire confiance à l'administrateur du serveur". Ca fait quand même beaucoup moins de monde d'un coup.
Mais pourquoi ne fais-tu pas confiance à l'admin système, c'est ça personnellement que je n'arrive toujours pas à cerner ?
Je veux légitimement sécuriser certains aspects de l'application.
Quand je fournis celle-ci à un client, si un utilisateur veut bidouiller quelque chose, l'administrateur est "de son côté" dans cette entreprise : il va aussi vouloir et pouvoir bidouiller.
Disons que pour moi, c'est toute l'entreprise qui est mon client (user, admin, serveur, ...), et c'est toute l'entreprise que je veux empêcher de trafiquer le code.
Et je me souviens que parfois, dans certaines petites entreprises (10-15 personnes) dans lesquelles j'ai eu l'occasion de travailler, tous le monde accède un peu comme il veut au serveur pour tous les types de problèmes.
Dans ce cas, tu peux toujours déporter les infos "sensibles" vers un serveur externe dont tu seras l'admin.
Evidemment, ça posera d'autres soucis (besoin pour le 'client' d'avoir une connexion internet active en permanence ; coûts de maintenance de ton serveur).
A voir si le jeu en vaut la chandelle, mais j'ai peur qu'il n'y ait pas d'autres alternatives (en tout cas j'en vois pas pour le moment).
Je vois toujours pas en quoi c'est un problème. Tu essaie d'empeche l'administrateur système, d'avoir accès au mot de passe d'une base de donnée qu'il gère et donc pour laquelle il connait déjà le mot de passe :s. Maintenant si l'admin donne le mot de passe à tout le monde, c'est pas ton cryptage qui va y changer quoi que ce soit.
Répondre avec citation
Partager