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.
Répondre avec citation
Partager