Voilà, cher journal ... j'ai un petit souci.
Je suis en train de développer un logiciel libre. Il est codé en java, et s'appuie sur une base Oracle.
Le logiciel en question peut être déployé sur un réseau de plusieurs machines locales, voire entre deux succursales d'une même entreprise, et doit se connecter à une même base de données.
Evidemment, cette base de donnée nécessite un login et un mot de passe.
Problème : pour l'instant, le mot de passe est dans un fichier txt dans le .jar qui constitue l'application. C'est clairement pas sécurisé. N'importe quel petit malin tombant sur le .jar aurait vite fait de chopper les identifiants de la base.
Alors comment faire ?
La solution qui m'ait venu à l'esprit est la suivante :
- Crypter de manière asymétrique ce mot de passe. Clef publique pour pouvoir le modifier au besoin, et clef privée pour quand le logiciel se connecte. Le problème reste en fait le même : je la met où cette *** de clef privée ? Dans le jar ? On obtient le même problème qu'antérieurement : on peut l'obtenir en ouvrant le .jar et en cherchant un peu.
- Ha oui mais alors il suffit de la mettre dans un .class, et à priori, ça devrait passer (à priori, je sais pas comment se passe le reverse engeneering d'un .class). Oui mais c'est GPL. Et c'est vendu avec les sources. Hmmm ... je vais quand même pas mettre la clef privée en clair dans le code.
Idée : faire une installation type qui génère les clef publique/clef privée, et une interface de configuration qui utilise la clef publique pour modifier le mot de passe. Hmmm. Certes, mais comment ?
Alors si quelqu'un a déjà rencontré un problème de ce type, et l'aurait contourné/résolu/autre(en java ou autre chose), qu'il me fasse signe, parce que ... je sèche.
PS : je sais pas vraiment comment se passe le cryptage de données en java pour l'instant donc si vous avez un joli exemple/une documentation ... ça me raccourcirait le travail.
Journal mot de passe et logiciel libre
3
mai
2004
# Re: mot de passe et logiciel libre
Posté par Colin Leroy (site web personnel) . Évalué à 2.
Si les utilisateurs de ton softs ne sont pas dignes de confiance, il te faudra une solution du genre:
backend lancé par un utilisateur privilégié, se connecte à la base de données avec le mot de passe
frontend lancé par les utilisateurs non fiables, se connecte au backend, sans authentification, via localhost ou une socket unix.
(pour info, décompiler un .class est chose aisée avec, par exemple, Jad sous windows - http://kpdus.tripod.com/jad.html(...) ).
[^] # Re: mot de passe et logiciel libre
Posté par iznogoud . Évalué à 1.
Si d'autres idées surgissent, je reste candidat.
PS : Ce soir ou demain, un autre problème tordu : problème d'affichage d'une page en perl-cgi avec dillo et links. (J'ai abandonné les css gérés de manière dégueulasse par IE, c'est vraiment de la merde ce navigateur.)
[^] # Re: mot de passe et logiciel libre
Posté par Nico . Évalué à 1.
c juste un fichier de conf qui est dans ton arborescence de ton systeme de fichier.
apres qu'il soit open source ou non t'es pas obligé de filer ton login, ton mdp et ton host de ta bdd dans les sources
[^] # Re: mot de passe et logiciel libre
Posté par iznogoud . Évalué à 2.
Cela dit, effectivement, ça marcherait, sauf que ... le logiciel est le même sur tous les postes. Et malheureusement, il y a de TRES TRES fortes chances pour qu'ils soient sous Windows, et les droits de fichiers spécifiques sous windows, j'y connais _rien_
PS : un prof avait dit une fois :
"windows c'est plus sécure que Linux en poste client ...
- et pourquoi, demande l'élève
- je vous file un terminal sous Linux, vous tapottez, et savez faire des trucs. Maintenant, je vous file cmd.exe et je vous dit "demerdez-vous" ...
- Ha ouais, effectivement ... j'saurai rien faire."
krkrkr
# mot de passe et logiciel libre
Posté par Pierre . Évalué à 3.
de stoquer cette valeur ou tu veux (pourquoi pas dans le jar).
Et lors de l'autentification, tu encode en md5, puis tu vérifie si les 2 md5 sont pareils.
Sachant qu'il est cryptanalytiquement difficile de repasser de md5 à mot de passe, tes mots de passe sont en sécurité.
Tiens d'ailleurs, le mien, c'est 9.KJKUlIclErB
[^] # Re: mot de passe et logiciel libre
Posté par Lawrence P. Waterhouse (site web personnel) . Évalué à 2.
Si j'ai bien compris, il n'y a pas d'authentification manuelle de l'utilisateur, l'appli se débrouille toute seule. Donc stocker le mot de passe "Maman" ou "9.KJKUlIclErB" revient au même.
[^] # Re: mot de passe et logiciel libre
Posté par Nico . Évalué à 2.
mon petit doigt me dit que ton md5 est un peu court... c'est 32 caractere le md5
je vois pas comment c'est possible ce que tu propose , il me semble en tout oracle ( je ne connais po bcp ) n'accepte les mot de passe en md5
ou alors c'est que tu stocke ton mot de passe en clair ds le .class ce qui n'avance a rien par rapport a le stocker ds le .jar
si je me trompe explique moi comment c possible
[^] # Re: mot de passe et logiciel libre
Posté par iznogoud . Évalué à 1.
Mais l'application doit effectivement se débrouiller seule pour se connecter. En d'autres termes, elle doit contenir quelque part l'information du mot de passe et doit pouvoir retrouver ce mot de passe en clair. Donc le md5 est prohibé. D'autre part, si je le crypte avec une clef publique, l'application aura en son sein une clef privée ... qu'il faudra bien stocker quelque part ... donc dans l'application. Donc je retombe sur le même point (même si il est alors plus difficile de trouver le mot de passe, ça reste très facile (on sait quel algo est utilisé (on a le source) et on a le source, on adapte, et on décode, 5 minutes chrono)
Donc ça va pas ... et je coince. Alors oui, l'utilisateur peut à priori être jugé digne de confiance dans la mesure où c'est des mauvais en info qui vont l'utiliser, et parce que à priori, c'est destiné à un réseau local ... mais on n'est jamais trop sûr. Et autant chercher à rassurer le client :)
[^] # Re: mot de passe et logiciel libre
Posté par Lawrence P. Waterhouse (site web personnel) . Évalué à 2.
# programmé en Java?
Posté par TazForEver . Évalué à 1.
voir l'interview de RMS
http://programming.newsforge.com/programming/04/04/07/2021242.shtml(...)
en gros : un logiciel libre qui dépend d'un logiciel non-libre n'est pas très utile ...
[^] # Re: programmé en Java?
Posté par romain . Évalué à 2.
- bossant exclusivement avec du logiciel propriétaire,
- bossant avec du logiciel libre tournant sur un os propriétaire,
en quoi leurs outils ne sont pas très "utiles", dans la mesure où ils leur permette de faire ce qu'ils veulent avec (ils ont un boulot, et le font bien).
Bon courage.
Promouvoir le logiciel libre, c'est une chose, avancer une ânerie pareille, c'est faire exactement l'inverse.
[^] # Re: programmé en Java?
Posté par TazForEver . Évalué à 1.
[^] # Re: programmé en Java?
Posté par romain . Évalué à 1.
Ne pas avoir du tout de logiciel libre (alternatif à un logiciel propriétaire) sur une plateforme propriétaire, c'est "mieux", sans doute ?
C'est un sérieux problème ?
[^] # Re: programmé en Java?
Posté par TazForEver . Évalué à 0.
je sais bien qu'il faut faire des concessions, mais il faut tendre vers du 100% libres ... utiliser du libre sur des systèmes propriétaires, c'est bien, c'est très bien ... seulement quand tu développes un logiciel sous licence libre et que celui ci dépend d'un logiciel propriétaire, et bien tu pièges ton utilisateur, tu l'oblige à accepter une licence dont il ne veut pas.
c'est bien beau de dire "hey je fais un logiciel libre et pi tout et tout" si tu utilises un runtime qui n'est pas libre ... aide toi toi-même
[^] # Re: programmé en Java?
Posté par romain . Évalué à 0.
Je ne piège personne ; l'utilisateur est libre d'utiliser mon soft ou non, surtout si celui-ci est libre. Il est même libre de le modifier pour qu'il tourne sur autre chose.
Un soft libre qui tourne sur un runtime propriétaire, ce n'est peut être pas très "pur" pour les puristes, il n'empêche que cela permet à ceux bossent nécessairement avec ce runtime, d'avoir des briques logicielles libres.
Les exemples de soft libres ne tournant que sous Windows sont légions.
Est-ce que je vais m'en plaindre ? Non, parce que :
- ce sont souvent des produits de qualité qui n'existent pas en propriétaire, qui tirent parfaitement parti de ce runtime,
- des équivalents pour les autres plateformes existent,
- si je veux qu'il ne dépendent pas de ce runtime, j'ai le droit d'aller toucher au source pour cela,
- je peux aller voir ailleurs.
Ca n'empêche pas qu'un tel programme, s'il est portable, c'est encore mieux.
Mais dire qu'un programme libre qui ne tournerait que sur un runtime proprio est inutile ou sans intérêt, c'est une énorme connerie : le but de l'histoire, ce n'est pas que le logiciel soit libre ou non, c'est que l'utilisateur ait la liberté de s'en servir de la façon qu'il souhaite.
Le fait que le logiciel soit libre est un moyen, non obligatoire, et une garantie, certainement.
C'est très bien d'être puriste, mais il faut savoir aussi poser les pieds sur terre, dans le monde bien réel, si on veut pouvoir promouvoir durablement et efficacement le logiciel libre.
[^] # Re: programmé en Java?
Posté par iznogoud . Évalué à -1.
Bon, on sort une carotte, un baton, et un fait geeeeeeeeeentilment sortir le troll d'ici :)
# mot de passe et logiciel libre
Posté par Patrice . Évalué à 1.
[^] # Re: mot de passe et logiciel libre
Posté par iznogoud . Évalué à 1.
[^] # Re: mot de passe et logiciel libre
Posté par Lawrence P. Waterhouse (site web personnel) . Évalué à 2.
Pour les appli web (client léger), le seul host à faire des acces base est celui qui fait tourner l'appli [J2EE|PHP|ASP]. Ca peut-être sur le même serveur que la base de donné ou une autre machine avec les droits nécessaires. Dans ce cas là, les login/passwd/host/port peuvent être dans n'importe quel fichier texte, de toute façon l'utilisateur chez lui n'y a pas accés.
Ta problèmatique - si j'ai bien compris - c'est que tu as un client "lourd", qui fait lui même l'accés à la base. Ton client doit donc s'authentifier. Donc deux solution :
- Les infos sont dans le code de l'appli. Faut espérer que personne va décompiler.
- Les utilisateurs ont leur propre login, a eux de ne pas faire les cons avec.
[^] # Re: mot de passe et logiciel libre
Posté par Lawrence P. Waterhouse (site web personnel) . Évalué à 1.
Pour les appli web (client léger), le seul host à faire des acces base est celui qui fait tourner l'appli [J2EE|PHP|ASP]. Ca peut-être sur le même serveur que la base de donné ou une autre machine avec les droits nécessaires. Dans ce cas là, les login/passwd/host/port peuvent être dans n'importe quel fichier texte, de toute façon l'utilisateur chez lui n'y a pas accés.
Ta problèmatique - si j'ai bien compris - c'est que tu as un client "lourd", qui fait lui même l'accés à la base. Ton client doit donc s'authentifier. Donc deux solution :
- Les infos sont dans le code de l'appli. Faut espérer que personne va décompiler.
- Les utilisateurs ont leur propre login, a eux de ne pas faire les cons avec.
# Problème insoluble ?
Posté par xilun . Évalué à 1.
Note que cela n'a strictement rien a voir avec le fait que le programme soit libre. En l'absence de source il en encore possible de tracer l'execution du programme en asm, en bytecode, en ce que tu veux, et en procédant par dichotomie assez rapide de decouvrir quand l'information est disponible. N'importe quel deplombeur de logiciel peut donc retrouver une telle info sans les sources en peu de temps si elle n'est pas obscursi par des techniques complexes et malheureusement peu fiables. Bref tout ca pour dire que la fourniture des sources ne produit pas un soucis complementaire.
Mais de tout ca on voit se degager une idée que tu avais toi meme ebauchée : le logiciel ne doit pas etre fournis avec les mdp inclus, ceux ci doivent etre configurés après l'installation. Mais il manque alors une condition importante : si l'utilisateur du logiciel n'est pas habilité à connaitre l'information, il ne faut pas qu'il puisse faire autre chose avec le logiciel _installé_ que l'executer : il faut donc generer une information secrete à l'installation stockée dans le soft installé, information qui donnera access à l'information permettant l'access à la base de données (en rw, ou avec de l'assymetrique en r et une info non stocké sur le HD pour le w), mais en plus de cela pour que cette info ne puisse s'echapper (ni l'info d'access à la db, qui est celle que l'on veut proteger avant tout) il faut interdire la lecture du binaire (pour empecher desassemblage et reverse). Cela necessite une gestion des droits qui dépasse simple cadre de la programmation Java (peut etre meme les noyeaux et les VM de base ? perso j'ai jamais eu a faire ca => chercher vers des patch orienté sécu), ainsi que la sécurisation physique des machines.
Avec tout ca je ne sais pas bien si j'ai été clair...
# Une proposition
Posté par Eul Guignol . Évalué à 1.
En fait les problèmes c'est surtout que tu ne veux pas que n'importe qui retouve le jar puisse se connecter sur ta base. Le mécanisme de sécurité doit donc se trouver du côté de la base.
Oracle est il capable de n'autoriser la connexion que depuis une liste d'IP par exemple ?
Sinon, il y a certainement moyen de mettre un petit proxy devant tout ça. Ainsi l'aspect sécurité est fait sur ton serveur.
Même si cette solution n'est pas fabuleuse, c'est du côté du serveur qu'il faut chercher la sécurité. Du côté client, tu ne sais pas comment ça va se passer. Et la dissimulation n'est pas une méthode de sécurisation, même si l'EUCD veut imposer le contraire par la loi ;-)
[^] # Re: Une proposition
Posté par iznogoud . Évalué à 1.
Bon, on va préciser un peu le projet, ça va peut-être en éclairer quelques-uns.
L'idée est de faire un logiciel de gestion de bibliothèques (prêts de livres, dvd, ...), en très simplifié (pas de fonctions superflus).
Pour préciser aux neu^trolleurs plus haut, le java est dans le cahier des charges, je choisis pas ... sinon je l'aurai fait en C/Gtk, sûrement (comme je le ferai pour le prochain projet que je ferai, mais cette fois, pour moi-même, pas pour le compte d'une société).
Imaginons.
La bibliothèque est grande, et il y a plusieurs postes disponibles, où l'utilisateur lambda, qui veut emprunter un livre, vient se connecter, et rentre ses coordonnées, le code du livre, et dit qu'il l'emprunte (bon, c'est pas forcément comme ça que ce sera utilisé, ce seront des assistants bibliothécaires qui le feront pour l'emprunteur).
Bon, on a plusieurs postes, plusieurs copies du logiciel, une seule BDD, un admin.
Alors si on a confiance en ses assistants, tout va bien (finalement, je crois que je le ferai comme ça ... tant pis). M'enfin, il suffit que l'un d'eux s'amuse, et ça va plus.
Note : tous les postes sont à mettre au même niveau (il y a pas de poste "supertoto" qui lui, a tous les droits, et les autres pourraient aller chercher dessus le fichier de conf).
Bon ben chaque appli doit comporter quelque part dans son entourage (l'ordi en lui-même cf la note), la donnée du mot de passe de la bdd.
PS : je prépare le prochain bug pour demain soir, il me résiste encore et toujours, malgré des feintes de sioux cherchées derrière les fagots.
[^] # Re: Une proposition
Posté par iznogoud . Évalué à 1.
On utilise Oracle (encore un prérecquis, m'enfin j'ai préparé dans mon coin en cachette une version mysql), et oui, oracle permet de n'autoriser la connexion que depuis une liste d'IP (enfin, à ce que j'en ai vu). M'enfin qui me dit que l'attaque ne viendrait pas du local (cf plus juste plus haut). Le mdp n'est à priori pas diffusé à grande échelle. Lire le post précédent pour comprendre un peu mieux (j'aurai du préciser avant, même si ton poste m'apporte des connaissances dont je te remercie de me les avoir apportées :))
Evidemment que dissimuler, c'est pas sécuriser. C'est justement pour ça que je me pose le problème.
[^] # Re: Une proposition
Posté par Colargol . Évalué à 2.
Il te suffit ensuite de créer un rôle permettant l'utilisation de ton appli et d'y rattacher les users oracle.
[^] # Re: Une proposition
Posté par iznogoud . Évalué à 1.
Seul souci de la dernière idée : la version MySQL que je fais dans mon coin tomberait alors à l'eau ... tant pis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.