Discussion :

[tchize_]

Est-ce suffisamment sécurisé ?

Ca le sera jusqu'au moment ou un malin / un key logger / un sniffer entrera sur le réseau et virera 5 années de données dans la table.

La sécurité par l'obscurité, c'est une très mauvais pratique.

[tchize_]

Si tu l'encode en SHA par exemple, et que tu passes par dessus avec un SALT, je défie tes users de trouver le mot de passe

Si ton application sait décoder le mot de passe (ce qui est inévitable), il me faudra pas une heure pour l'avoir personellement.

[ruscov]

Jasypt est notamment utilisé pour crypter les password dans les configs hibernate.

Jasypt provides the org.jasypt.properties.EncryptableProperties class for loading, managing and transparently decrypting encrypted values in .properties files, allowing the mix of both encrypted and not-encrypted values in the same file.

Le principe c'est que tu encrypte le password dans ta config avec un password que toi seul connait et que tu hardcode dans ton programme.
Le jour où le password de ta DB change, tu ne dois pas recompiler. Tu dois juste ré-encrypter ton password grâce au password que toi seul connait.

Si tu utilises l'ago SHA, le seul moyen de trouver le password, c'est de faire du brute force et là, ben tu mettras plus qu'une heure

[tchize_]

Ton programme dois connaitre ce mot de passe pour pouvoir ce connecter à la DB. Pour le récupérer, j'ai les choix suivant:

1)j'injecte un driver jdbc bidon qui prend quelques lignes à écrire et qui, au lieu de se connecter, m'affiche le mdp dans la console
2)j'appelle directement la méthode de ton code qui charge et décrypte la config et j'ai le fichier en clair
Je n'ai pas besoin de casser un code. Ton programme dois pouvoir en local décrypter le mdp de la base de donnée => C'est une faille simple à exploiter.

Ce système de cryptage de config ne peux marche que si l'utilisateur n'a pas accès au mot de passe de décryptage.... mais si il n'y a pas accès, alors ton programme non plus, et tu ne sais pas décrypter donc pas te connecter. On utilise normalement ces systèmes dans des serveurs, quand on veux qu'on nombre restreint d'administrateurs puisse avoir toutes les informations nécessaires au décryptage. Ou pire, au démarrage de l'application, on demande à un super admin de se logguer pour encoder le mot de passe => il n'est même pas dans le système de fichier.

Tout ton problème ici, c'est qu'un environnement non contrôlé (l'utilisateur final) a besoin in fine d'un mot de passe pour accéder à la base de donnée. Et là t'as deux possiblités:

1) tu mitige les risque en fournissant un compte différent à chaque utilisateur (et tu gère les droit coté serveur, comme il se doit), ce que je recommande
2) tu laisse tous les utilisateurs se connecter à la db avec le même mot de passe. Et là, tu peux le protéger tant que tu veux, l'utilisateur pourra toujours le récupérer, puisque le programme le peux. C'est le problème paradoxale du "comment rendre le mot de passe indecodable sur la machine A tout en laissant le mot de passe decodable sur la machine A"

[ruscov]

tu laisse tous les utilisateurs se connecter à la db avec le même mot de passe. Et là, tu peux le protéger tant que tu veux, l'utilisateur pourra toujours le récupérer, puisque le programme le peux. C'est le problème paradoxale du "comment rendre le mot de passe indecodable sur la machine A tout en laissant le mot de passe decodable sur la machine A"

Ce "paradoxe" est contourné avec Jasypt puisque le mot de passe pour décoder le mot de passe crypté dans ton fichier de config est hardcodé dans ton appli. Donc à moins de décompilé l'application, l'utilisateur n'a pas accès à ce mot de passe.
Je ne sais pas qui sont les end users de l'application mais je ne pense pas que ce soit des génies du hack.

[tchize_]

on en reviens à la sécurité par l'obscurité, c'est une MAUVAISE pratique, très mauvaise, et la source de grosses emm**

C'est bien si t'as juste deux trois bidouille à protéger.

Si tu utilise ça pour protéger des données à caractère personnel (base de données clients, ressources humaines, etc.) tu peux alelr jusqu'à te retrouver avec un procès aux fesses pour ta négligence

C'est du même niveau que de laisser trainer de l'injection SQL sur ton serveur web en disant "ho de toutes façons, mes utilisateurs ne connaissent pas le SQL"

[rg77140]

Je suis moins tranché que toi tchize_ sur le niveau de sécurité à mettre en place. Tout dépend du contexte et de la criticité des données... Quand tu dis :

on en reviens à la sécurité par l'obscurité

Tout est sécurité par obscurité. Rien n'est inviolable. Des failles il y en a partout, dans toutes les plateformes, dans tous les logiciels. Tout est question de niveau de sécurité et de criticité des données, de l'impact d'un éventuel hack, de la capacité à corriger le hack, ...

Si tu mets le mot de passe en clair dans un fichier properties, la personne doit savoir décompresser un war et chercher dans des fichiers, si tu encodes le mot de passe alors elle doit savoir injecter du code ou faire du reverse engineering, si tu lui donnes un user avec que l'accès en lecture alors la personne pourra toujours tenter de se connecter à ta base en force brut avec un autre user, ou essayer de se connecter en ssh à ta machine, etc etc etc...

Bref rien n'est inviolable...

Code :

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

1
2
3
while(coutHack > coutMiseEnPlaceSecurite){
     augmenterSecurite();
}

Romain.

[tchize_]

la différence, c'est que la war (et donc le mot de passe) n'est jamais dans les mains de l'utilisateur. Alors qu'ici t'es occupé de le répliquer sur les machines users.

Dis à ton DBA que *le* mot de passe pour la DB avec les droit d'écriture est stocké sur toutes les machines des utilisateurs et regarde sa tête après...

[rmartinsfidalgo]

Il y a dans ce post un amalgame que je trouve dangereux.

tchize_ tu parles de quoi exactement d’un utilisateur DB ou d’un utilisateur applicatif, car ce sont deux choses totalement diffèrent….

Dans la majorité des cas des applications Java type web, je simplifie naturellement, c’est au niveau DB on configure 1, je dis bien 1, utilisateur DB avec schema et privilège spécifique et limité pour l’application. Cet utilisateur DB sera configurer au niveau d’un fichier config, exemple pour Tomcat dans le server.xml, dont le mot de passe est toujours en claire. Ensuite au niveau de l’application, on peut ajouter autant d’utilisateur avec rôles et tout le bataclan que l’applicatif a besoin, qui eux se trouve avec le mot de passe (crypté, en tout cas cela devrait être le cas) en base dans une table souvent appeler User.

Tu es entrain de dire que ceci est totalement faux ?

Maintenant que l'admin DB ne soit pas dans l'application, je trouve cela totalement normal et justifie comme tu dis pour des raisons de sécurité, mais faire tout la gestion utilisateur avec rôles et tout le bataclan, je parles d'utilisateur applicatif, c'est lourd et trop chère (faudrait un DBA par application)... Et je connais aucuns projets dans mon secteur qui le fait. Tous passe par des Framework type Spring Security.

[tchize_]

Tu es entrain de dire que ceci est totalement faux ?

Non, je dis juste qu'ici on est pas du tout dans ce shéma, on est dans le schéma d'une application de bureau, autrement dit l'accès DB se trouve sur chaque poste utilisateur. En tout cas c'est comme ça que je l'ai compris, mais en relisant les posts, effectivement, ce n'est pas explicité, juste que les utilisateur vont utiliser son application java... Donc je pense que toi et moi on est occupé d'argumenter sur deux choses différentes


bien sur, pour moi la gestion applicative des droit est une bonne chose, dans un serveur, mais pas dans une appli desktop, qui elle peut être contournée par n'importe quel user

[Seuub]

Merci pour vos réponses

Mon application étant sur desktop je vais gérer mes utilisateurs directement sur SQL Server