Discussion :

[khaled_prg]

Salut tout le monde

Je compte développer une application open source en Java qui permet de gérer les mots de passe. l'idée m'est venue à l'esprit pour deux raisons :
1. J'enregistrais mes passwords dans un fichier texte (caché et portant une fausse extension ! mais bah, je sais quand même que c'est pas sécurisé)
2. Je veux améliorer mes connaissances en développement et cryptographie.

Pour ce faire, j'ai besoin d'une base de données, dans laquelle, je vais sauvegarder l'ensemble des mots de passe après les avoir chiffré bien sûr.
Maintenant, je vous demande, est-ce que l'utilisation des fichiers XML comme support de sauvegarde est acceptable ? puisque je veux que l'application soit portable, donc je ne dois pas utiliser une BD de type client-serveur.



Merci d'avance.

[benratti]

Pour ce faire, j'ai besoin d'une base de données, dans laquelle, je vais sauvegarder l'ensemble des mots de passe après les avoir chiffré bien sûr.
Maintenant, je vous demande, est-ce que l'utilisation des fichiers XML comme support de sauvegarde est acceptable ? puisque je veux que l'application soit portable, donc je ne dois pas utiliser une BD de type client-serveur.

Pour une application mono-utilisateur, en stand-alone, des fichiers xml peuvent faire l'affaire.

Pour ce faire, j'ai besoin d'une base de données, dans laquelle, je vais sauvegarder l'ensemble des mots de passe après les avoir chiffré bien sûr.

Pour ce type d'utilisation, penses bien la manière dont vas stocker la clé de chiffrement... ca peut devenir une grosse faille si cela est mal géré!

[nchal]

Bonjour,

Je pense qu'avoir un fichier xml pour stocker tes mots de passe est une idée assez bonne dans l'optique d'approfondir tes connaissance en Java.
Tu vas pouvoir apprendre à créer et parser un fichier xml, tu peux même t'amuser à faire une petite IHM pour avoir un rendu assez sympa.
Pour le cryptage, pourquoi pas partir sur du MD5 ? Je m'y connais pas trop en sécurité mais il me semble que c'est le cryptage de base.
Après tu peux faire ton propre cryptage, le plus simple est de faire un cryptage XOR, c'est à dire tu fais un OU exclusif avec une clef qui tu as défini sur ton mot de passe pour le crypter et tu refais la même chose pour le décrypter (le cryptage XOR est symétrique). Ci joint un lien qui explique ça assez clairement (http://www.primenumbers.net/Renaud/fr/crypto/XOR.htm)

[benratti]

Pour le cryptage, pourquoi pas partir sur du MD5 ? Je m'y connais pas trop en sécurité mais il me semble que c'est le cryptage de base.

MD5 est ce que l'on appel une fonction de hashage, cela signifie notamment que ce n'est pas réversible... Le stockage d'un hash à la place du mot de passe est utiliser pour les systèmes d'authentification. Cela permet de vérifier que le mot de passe de l'utilisateur correspond bien à celui saisi. Cela vient notament du fait que si hash(password1) == hash(password2) alors on peut en déduire que password1 == password2. Il faut pour cela que la fonction de hashage utilisée n'ait qu'un faible taux de collision, c'est à dire un nombre de résultats identiques faibles pour des entrées différentes. Il s'avère que md5 n'est pas vraiment le meilleur pour cela.

Par contre, comme tu l'as surement compris, une fonction de hashage n'étant pas réversible, tu ne pourras pas récupérer tes mots de passe. dommage. Utilises donc plutot une fonction de chiffrement.

Après tu peux faire ton propre cryptage, le plus simple est de faire un cryptage XOR, c'est à dire tu fais un OU exclusif avec une clef qui tu as défini sur ton mot de passe pour le crypter et tu refais la même chose pour le décrypter (le cryptage XOR est symétrique). Ci joint un lien qui explique ça assez clairement (http://www.primenumbers.net/Renaud/fr/crypto/XOR.htm)

Si tu as envie de découvrir les algos de chiffrements de bases, pourquoi pas recoder le XOR, par contre, il faut que tu saches que celui si n'est pas vraiment robuste. Je t'invites également à ne jamais recoder toi même les algos de chiffrement mais à utiliser des implémentations réputées correctes et sans faille connues (sauf bien sur si tu c'est ton job d'implémenter des algos de chiffrement).

[nchal]

Re,

Effectivement, si le MD5 n'est pas réversible, ça ne va pas être pratique
Je trouvais mon idée de recoder le XOR, plutôt bonne car c'est également un bon moyen de découvrir des nouvelles choses en Java (opération sur les strings)
Il est vrai que tu n'as pas expliqué pourquoi tu veux crypter tes mots de passes mais effectivement, si tu refais l'algo, il faut faire attention où tu stocke ta clef, car si elle est lisible par une tierce personne, ton chiffrement tombe à l'eau.

[khaled_prg]

@benratti et @nchal
Merci beaucoup pour vos remarques pertinentes.

J'ai discuté hier avec un ami, développeur en Java, il m'a conseillé d'utiliser une base de données SQLite pour stocker les mots de passe, avec la possibilité d'exporter les données sous formats XML, HTML ou TXT. Qu'en pensez-vous ?

Sinon, y a encore deux grandes questions qui me prennent souvent la tête :
- La BD SQLite doit être cryptée à tout moment, comment puis-je y connecter et travailler là-dessus ? (Dois-je utiliser une méthode telle que SealedObject ? )
- Je compte utiliser MD5 pour vérifier l’intégrité de la base lors de l'importation par exemple, et AES pour chiffrer la BD. Maintenant, pour le mode CBC, est-ce que AES l'utilise implicitement ou je peux l'utiliser d'une façon explicite pour renforcer la résistance de l'algo ?



Merci encore une fois.

[Sennad]

Salut !

Pourquoi tu veux crypter ta BDD ?
C'est le mot de passe qui le sera, pas ta BDD nan ? Ou alors j'ai mal compris ce que tu veux faire.
Mais pour moi tu as tes mots de passes crypté de stocké dans ta DB, et pour savoir ton mot de passe réel ton appli java va le décrypter.
Je comprends pas trop pourquoi crypté la DB ?

[Sennad]

Et en ce qui concerne la DB SQLite moi je dis oui, âpres je suis pas expert, à voir avec d'autres personnes.

[miaous]

bonjour

si la base n'est pas chiffré les informations sont contenue en clair dans la base donc lisible par n'importe qui.

le mieux est d'avoir un mot de passe qui sert de clef pour chiffre/déchiffre la base .
après soit tu chiffres les fichiers de la base ou tu chiffres les informations (colonnes) que tu veux protéger ( login / motdepass ) .

[nchal]

bonjour

si la base n'est pas chiffré les informations sont contenue en clair dans la base donc lisible par n'importe qui.

le mieux est d'avoir un mot de passe qui sert de clef pour chiffre/déchiffre la base .
après soit tu chiffres les fichiers de la base ou tu chiffres les informations (colonnes) que tu veux protéger ( login / motdepass ) .

Justement, si le mot de passe est chiffré, il peut être stocké "en clair", ça reste illisible. Et ça me semble le plus simple à faire quand même.
Tu stocke ton mot de passe chiffré et tu le récupère en le déchiffrant.

[Sennad]

Justement, si le mot de passe est chiffré, il peut être stocké "en clair", ça reste illisible. Et ça me semble le plus simple à faire quand même.
Tu stocke ton mot de passe chiffré et tu le récupère en le déchiffrant.

C'est ça que je voulais dire, si le mot de passe est chiffré et pourquoi pas le login aussi, la DB n'a pas besoin d'être chiffrée, c'est quand même plus facile à réaliser je pense.
Et après tu peu effectivement demander un mot de passe au lancement de l'application, qui lui est haché par un MD5 par exemple, et du vérifie si les deux sont identique.
Je reprends parce que ça n'a pas l'air bien clair ce que je viens de dire.
Tu choisi une clef de chiffrage / déchiffrage, par exemple "maClef".
Tu la hache une fois, tu stocke ce hash dans ta DB.
Au lancement de l'appli on demande le mot de passe, tu entre "maClef", et la ton appli java le hash et compare ce hash avec celui de la db.
Si ( hash(clefEntrée) == hashClefStocké ) ça veut dire que clefEntrée = ClefStocké donc c'est bon.
Et là ta pas un seul mdp en clair.

J'espère avoir était assez clair.

[khaled_prg]

@Sennad

Pourquoi tu veux crypter ta BDD ?

Pour augmenter la sécurité de mon application.
En plus des mots de passe, est-ce possible de chiffrer la BD aussi ?

@nchal

Justement, si le mot de passe est chiffré, il peut être stocké "en clair", ça reste illisible. Et ça me semble le plus simple à faire quand même.
Tu stocke ton mot de passe chiffré et tu le récupère en le déchiffrant.

Donc les autres informations restent lisible par n'importe qui ?
En plus, je me demande, si la BD est récupérée par qqn, quelle est la probabilité de casser les mots de passe chiffrés avec AES-128 ?

Je reprends parce que ça n'a pas l'air bien clair ce que je viens de dire.
Tu choisi une clef de chiffrage / déchiffrage, par exemple "maClef".
Tu la hache une fois, tu stocke ce hash dans ta DB.

Je le stocke dans la base, mais où exactement ? dans une colonne à part ou quoi ?


Enfin, je répète la question concernant le mode de chiffrement, quel est le mode conseillé qu'on doit utiliser avec AES ? CBC ou OFB ?

[Sennad]

Pour augmenter la sécurité de mon application.
En plus des mots de passe, est-ce possible de chiffrer la BD aussi ?

Je ne sais pas si c'est possible, mais si toutes les données de ta DB sont chiffrées je ne vois pas l'utilité.

Donc les autres informations restent lisible par n'importe qui ?
En plus, je me demande, si la BD est récupérée par qqn, quelle est la probabilité de casser les mots de passe chiffrés avec AES-128 ?

Les données restent lisibles certes, mais tu vas lire du charabia quoi
Tu peux toujours chiffrer chaque donnée que tu insères dans ta DB et les déchiffrer quand tu veux t'en servir.
Avec du Bruteforce ça doit pouvoir se faire mais bon..

Je le stocke dans la base, mais où exactement ? dans une colonne à part ou quoi ?

Tu peux créer une table juste pour ça, une table Employees ou quoi qui modélisera des utilisateurs ( login / mdp ) qui ont accès à tes données.
Tu peux même jouer sur ça pour afficher des données restreintes pour un utilisateur moins important ou quoi (il aura accès qu'a certaines tables, ou qu'a certaines vues par exemple), et avec un user Admin qui lui peut tout voir par exemple.
Je pense que cette approche peut être intéressante pour ton appli.

[khaled_prg]

Merci Sennad pour l'aide, +1.

Je ne sais pas si c'est possible, mais si toutes les données de ta DB sont chiffrées je ne vois pas l'utilité.

Je suis pas sûr mais si par exemple, le pirate ouvre le code de la base avec un éditeur SQLite, au mois, il verra en clair sa structure, du coup, il saura des informations de plus sur le support de stockage ! ou je me trompe ?

Les données restent lisibles certes, mais tu vas lire du charabia quoi
Tu peux toujours chiffrer chaque donnée que tu insères dans ta DB et les déchiffrer quand tu veux t'en servir.
Avec du Bruteforce ça doit pouvoir se faire mais bon..

Pour chaque chiffrement d'un mot de passe, j'aurai une clé de taille 128 bits si je fais AES-128, où dois-je stocker l'ensemble des clés ?

Tu peux créer une table juste pour ça, une table Employees ou quoi qui modélisera des utilisateurs ( login / mdp ) qui ont accès à tes données.

Tu m'as pas compris, je parlais du hash, où dois-je le stocker ?

Tu peux même jouer sur ça pour afficher des données restreintes pour un utilisateur moins important ou quoi (il aura accès qu'a certaines tables, ou qu'a certaines vues par exemple), et avec un user Admin qui lui peut tout voir par exemple.

Pour cette application, tous les utilisateur auront les même privilèges, je vois pas vraiment à quoi sert une telle idée ?

[Sennad]

Merci pour le +1 Je suis nouveau sur le forum, j'avais un problème, on m'a très rapidement aidé, du coup j'ai vraiment apprécié, et je me suis lancé, je pense essayer de rédiger un petit article bientôt
Je viens de passer Nouveau Membre du Club j'suis content

Je suis pas sûr mais si par exemple, le pirate ouvre le code de la base avec un éditeur SQLite, au mois, il verra en clair sa structure, du coup, il saura des informations de plus sur le support de stockage ! ou je me trompe ?

Peut-être, je veux pas dire de bêtises ^^

Pour chaque chiffrement d'un mot de passe, j'aurai une clé de taille 128 bits si je fais AES-128, où dois-je stocker l'ensemble des clés ?

Je suis pas sûr d'avoir bien compris, mais ta clef de chiffrement sera le mot de passe que l'on te demande au démarrage de l'application.

Tu m'as pas compris, je parlais du hash, où dois-je le stocker ?

Et bien tu le stocke dans une colonne CryptedPassword de ta table Employees (C'est un exemple, mais ça suis la logique de ce que j'ai écrit au-dessus)

Pour cette application, tous les utilisateur auront les même privilèges, je vois pas vraiment à quoi sert une telle idée ?

Je pensai à ça car j'imaginai que ton appli pourrait être utilisé par plusieurs personnes, plus ou moins bien placé dans l'entreprise par exemple.
Mais si tu n'en a pas l'utilité c'est pas la peine ^^

Ps : Désolé pour les balises Quotes ca marche pas je comprend pas pk.
J'aimerai aussi mettre une signature automatique mais j'ai pas trouvé, si quelq'un sait ( On sait jamais hein )

[tchize_]

Tu pourrais t'inspirer de ce que fait l'outil KeePass destiné à ça sous windows, regarde ça doc et tu comprendra qu'il faut beaucoup de choses pour biens sécuriser tes mots de passe.

concernant le stockage, allez jouer à crypter la base de données SQLite, c'est un peu se tirer la nouille de manière compliquée. Et en cryptographie / sécurité, compliqué, c'est synonyme de erreur et erreur c'est synonyme de trou de sécurité

Donc garde des choses simple, mais efficace. Par exemple, tu peux stocker l'ensemble de tes données dans un XML que tu chiffre à la volée. Chiffrage que tu réalise en utilisant un clé, clé que tu génère à partir d'un mot de passe maître que l'utilisateur doit absolument taper dans ton programme. Comme le xml est chiffré, tout est chiffré, tout à la protection qu'apporte l'algorithme de chiffrement. Comme la clé n'est jamais stockée, elle risque peu de se faire voler. Je ne vois pas trop l'intérêt d'une "base de données". Ton programme ne va pas stocker 5000 mots de passes pour 200 utilisateurs différents. Tu aura un seul utilisateur et au mieux quelques dixaines de mot de passe. Donc au final une seule table avec une 50 aine de lignes. Autant dire que l'aspet 'relationel' de la base sera loin d'être utilisé

A note que ça ne suffit pas encore théoriquement. Mais pour un premier programme on va pas être trop chien

A prévoir après pour n vrai programme :
Tu dois aussi t'arranger pour que le mot de passe / la clé ne soit jamais transféré vers la swap, donc que la zone mémoire où tu le stock soit non swapable => ce qui est impossible à faire en java à ma connaissance
Tu dois t'arranger pour que les mots de passe ne puissent pas être intercéptés par un programme qui sauvegarderais le presse papier. Keepass fais ça en machouillant le mot de passe dans tous les sens et en le combinant à des simulations de touches gauche / droite / delete / backspace
Tu dois t'arranger pour que le mot de passe / les mots de passe disparaissent de la mémoire de ton programme dès que l'on passe en hibernation => impossible en java encore une fois

[khaled_prg]

Merci Sennad.

@Tchize +1

Tu pourrais t'inspirer de ce que fait l'outil KeePass destiné à ça sous windows, regarde ça doc et tu comprendra qu'il faut beaucoup de choses pour biens sécuriser tes mots de passe.

Je l'ai déjà téléchargé, il est parfait, j'ai vu le guide d'utilisation mais pas la documentation technique ! où puis-je la trouver ?
En plus, je me souviens que KeePass permet de saisir l'ensemble des mots de passe, et demande l'enregistrement en dernier lieu, est-ce possible avec une BD SQLite ? (Je pensais qu'on doit tout d'abord créer la BD !)

concernant le stockage, allez jouer à crypter la base de données SQLite, c'est un peu se tirer la nouille de manière compliquée. Et en cryptographie / sécurité, compliqué, c'est synonyme de erreur et erreur c'est synonyme de trou de sécurité

C'est compris, je veux plus crypter la BD

Donc garde des choses simple, mais efficace. Par exemple, tu peux stocker l'ensemble de tes données dans un XML que tu chiffre à la volée. Chiffrage que tu réalise en utilisant un clé, clé que tu génère à partir d'un mot de passe maître que l'utilisateur doit absolument taper dans ton programme. Comme le xml est chiffré, tout est chiffré, tout à la protection qu'apporte l'algorithme de chiffrement. Comme la clé n'est jamais stockée, elle risque peu de se faire voler. Je ne vois pas trop l'intérêt d'une "base de données". Ton programme ne va pas stocker 5000 mots de passes pour 200 utilisateurs différents. Tu aura un seul utilisateur et au mieux quelques dixaines de mot de passe. Donc au final une seule table avec une 50 aine de lignes. Autant dire que l'aspet 'relationel' de la base sera loin d'être utilisé

SQLite est légère et limitée aussi, je préfères l'utiliser
En ce qui concerne le chiffrement du fichier XML, j'ai pas bien compris. Dois-je chiffrer le fichier en tant que tel ou seulement certains champs ?

[tchize_]

Merci Sennad.

@Tchize +1

Je l'ai déjà téléchargé, il est parfait, j'ai vu le guide d'utilisation mais pas la documentation technique ! où puis-je la trouver ?

http://keepass.info/help/base/security.html

[khaled_prg]

Merci, +1.

Une denière question :
Si je chiffre les deux colonnes, login et password, pour chaque chiffrement (enregistrement), j'aurai une clé de taille 128 bits, où dois-je stocker l'ensemble des clés ?


Merci d'avance.

[tchize_]

Dans un fichier, un enregistrement, que tu chiffre avec le mot de passe maitre choisi par l'utilisateur.