Discussion :

[yotta]

Bonjour,
Je débute dans l'usage d'EclipseLinck et de la persistance JPA 2.1.
Mon soucis concerne la sécurité.
Le fichier de persistance "persistence.xml" que je ne maîtrise pas et qui pour l'heure ne contient que des directives très basiques contient le nom de l'utilisateur, du serveur, de la base de données cible et bien sûr le mot de passe en claire ?!
Il y a certainement une raison à cela qui m'échappe encore.
Comme pour l'instant j'évolue toujours dans un environnement Java SE et que mon programme est une application lourde autonome, il contient son fichier de persistance, lequel devient du coup accessible à tous les utilisateurs du logiciel.
Comme n'importe quel outil de décompression permet de voir le contenu d'un fichier jar, et donc de visualiser le contenu de persistence.xml, je trouve cela incroyablement léger en terme de sécurité. Je penses plutôt que ce n'est pas comme ça qu'il faudrait utiliser la persistance, mais peu importe, j'aimerai juste savoir s'il existe un moyen de faire en sorte que l'information de mot de passe soit présente sous forme cryptée dans le fichier de persistance ?

[tchize_]

Si tu as une application lourde et qu'elle se connecte directement à ta base, tu as d'office des problèmes de sécurité, quel que soit le moyen utilisé (JPA ou autre). La seule chose plus ou moins sécurisée serait de donner un login / password base de données à chaque utilisateur. Mais tu risque de galérer pour gérer les permissions coté database, savoir qui peut faire quelles requêtes, ... En général, on va plutôt mettre un serveur type REST ou XMLRPC qui gère la logique business, la sécurité et les accès DB (éventuellement avec du JPA pour la gestion du modèle de stockage) et l'application lourde utilisera des api REST pour toutes ses demandes, n'étant au final que l'UI. La logique de sécurité restant ainsi dans le serveur.

Pour ce qui est du persistence.xml, il faudrait nous en direun peu plus sur comment tu intègre JPA. Par exemple, le persistence.xml peut référence une datasource. Ou si tu crée l'entitymanager à la main, tu peux fournir la connection lors de la création de l'entitymanager. Tu utilise quoi pour ton application? uniquement eclipselink? Spring boot? autre chose? Sachant que de toutes façons, du JPA coté desktop, ce sera d'office un cauchemar sécurité à gérer.

[yotta]

Bonjour Tchize_,
Merci pour ton intervention.
Tes explications me permettent de comprendre que de manière "naturelle", je me suis tourné vers ce type de fonctionnement. Mon application est concrètement plus complexe que la description que j'ai donné. En fait, j'ai écrit un programme de type serveur qui tourne sur le serveur qui héberge MySQL, ce dernier étant configuré pour n'accepter que les connexions locale. Donc, impossible, même en possédant un identifiant, de se connecter à ce serveur depuis une autre machine de manière directe, y compris pour mon programme client. Lorsque ce dernier a besoin d'informations issues de la base de données il s'adresse à mon programme serveur via une connexion par socket et un dialogue texte type question/réponse pour soumettre ses requêtes et obtenir ses réponses au format json. Cela signifie que JPA est utilisé par mon programme serveur et sa sécurité se fait au niveau système de fichiers. Donc, dans l'absolue, il n'est pas grandement utile de protéger le mot de passe contenu actuellement dans le fichier de persistance dont le contenu est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="CIAO_LIBPU" transaction-type="RESOURCE_LOCAL">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <properties>
      <property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost:3306/MCIAO?zeroDateTimeBehavior=convertToNull"/>
      <property name="javax.persistence.jdbc.user" value="MCIAO"/>
      <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
      <property name="javax.persistence.jdbc.password" value="mot de passe"/>
    </properties>
  </persistence-unit>
</persistence>

En résumé, cette question n'est que simple curiosité car c'est en manipulant JPA que je me suis rendu compte de la clarté du mot de passe en son sein, et j'ai trouvé ça très étonnant. Dans ma logique, stocker un mot de passe se fait toujours de manière cryptée quelle que soit le contexte, jamais en clair.
Je me suis alors demandé s'il existait un moyen au niveau de JPA de faire en sorte que dans ce fichier, le mot de passe n’apparaisse pas en clair, mais crypté, sans pour autant avoir a gérer la partie cryptage/décryptage. Mais en effet, comme tu me le décrits, ce n'est pas conçu pour être embarqué dans les interfaces utilisateurs classiques, donc, JPA n'offre pas de mécanisme de sécurisation de cette information, ce qui répond à ma question.
En fait, la seule solution que j'ai trouvé de sécuriser le mot de passe est de ne pas le renseigner dans le fichier de persistance. En effet, je crée manuellement mon instance EntityManager, ce qui m'offre l'opportunité de fournir le mot de passe a posteriori. Je stock le mot de passe sous forme cryptée dans un fichier texte, et mon programme sait le décrypter pour renseigner mon EntityManager.

[tchize_]

Alors oui c'est une mauvaise pratique de stocker les mots de passe en clair.... Pour le serveur recevant la demande d'authentification. Mais les outils qui ont besoin de ces mots de passe pour se connecter doivent bien les recevoir de quelque part. Il existe bien des solution (en spring je pense) pour crypter tes fichier properties, mais c'est le problème de la poule et de l'oeuf. Ton programme a besoin de connaitre un secret pour pouvoir lire ce fichier properties et ce secret... il faut le protéger. A moins qu'un opérateur ne tappe à la main le mot de passe à chaque redémarrage de ton app server, je ne vois pas de moyen de coper au stockage du secret (que ce secret soit le mdp ou la clé pour le décrypter). C'est un problème mineur car
1) ce mot de passe n'est en général utilisé que par un seul service et peut donc être changé
2) pas de risque de "même mot de passe partout"
3) tu peux vérouiller les droits sur le filesystem.

Après ce qu'il faut éviter de faire, c'est de stocker ce mdp dans ton repository de source

[yotta]

Tout à fait, Tchize_, il y aura toujours un secret ultime à l'origine de n'importe quelle protection qu'il faut impérativement protéger. C'est pour cette raison que je cherche en ce moment le moyen de stocker ma clé de cryptage/décryptage dans un keystore, solution qui me semble plus sécurisée qu'un simple fichier binaire. Mais dans ce cas, il faudra que le programme fournisse le mot de passe d'accès au keystore, etc, etc... On finit effectivement par rebondir sur un autre secret encombrant. Donc, j'ai abandonné l'idée.
Cependant, je me suis demandé s'il existe un moyen de procéder un peu comme le font les navigateurs avec les applets. A savoir, utiliser la signature de code pour identifier ce dernier et lui donner alors accès sans contraintes de mot de passe à ses ressources. Je ne suis pas encore au fait des technologies comme REST, qui je suppose utilise un principe d'identification similaire et s'appuie probablement sur un certificat. D'ailleurs, j'ai remarqué qu'il existe des guides pour mettre en place la technologie REST sur un serveur Glassfish. Je viens d'en installer un que j'ai pu rendre fonctionnel comme je le voulais (grâce un peu à toi d'ailleurs dans un poste précédent où tu m'as aidé), mais c'est beaucoup de choses d'un coup pour ma veille cervelle, alors je vais y aller doucement.
Merci pour ton intervention Tchize_, elles sont toujours instructives.