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
cryptage de fichier
Bonjour,
j'ai realisé une petite appli qui contient des parametres de connection a une BDD et d'autres preferences.
J'aimerais conserver ces preferences et les recharger a chaque lancement.
je part sur l'idée de mettre tout ca dans un fichier et de l'encrypter bettement a un endroit
pourriez vous me conseiller?
quel cryptage?
facon la plus simple...
merci d'avance
- tu peux consulter le package javax.crypto où tu trouveras pas mal d'infos
- tu peux implémenter toi même une petite méthode de cryptage/décryptage, sans framework, selon le niveau de confidentialité que tu veux obtenir.
Par exemple un petit cryptage poly-alphabetique.
Cela est très simple à implémenter mais reste aussi simple à décrypter pour celui qui a envie d'essayer.
n'oublie pas que, quel que soit le cryptage que tu choissise, à moins que ça implique que l''utilisateur tappe une clé de cryptage, ce sera réversible facilement, et donc d'un intérêt moyen. Ce sera juste de l'obfuscation.
y a t'il un moyen simple de generer une clef de chiffrement composée d'une clef hard et d'une masquée dans le nom du fichier?
Salut,
Il faut bien comprendre que sans intervention de l'utilisateur (entrée d'un mot de passe, ...), il faudra à un moment donné que tu écrives une clef en clair dans un fichier. A aprtir de là, la sécurité n'est plus qu'une illusion...
Qu'entends tu pas clef hard ?
par clef hard j'entend une clef fixée en parametre dans le programme.
je suis d'accord avec toi, la securité n'est pas absolue, mais je veux juste un chiffrement simple a mettre en place.
maintenant si l'un de vous me donne une solution miracle... enfin je veux dire simple et a la fois relativement sécurisée... bah j'aurais posé ma question au bon endroit!
par ma question precedente, j'immaginais une clef resultante d'une partie dure dans le programme (un parametre que je pourrais faire evoluer plus tard...) et d'une partie variable dans le nom du fichier (par ex: le debut et la fin me permettre d'identifier le fichier et le millieu est la partie variable de ma clef)
... comme ca l'utilisateur ne sais pas d'ou viennent ses parametres... magique
c'est couillon comme idée?
Le problème n'est pas tant l'algorithme.
Il vient surtout du fait que l'utilisateur mal intentionné, peut décompiler ton application pour retrouver l'algo de cryptage.
Pas du tout. Il faut simplement que la complexité de codage de la solution soit équivalent à l'intérêt pour quelqu'un de cracker ton cryptage.Envoyé par igorzup
Par exemple, il serait idiot de mettre un code de César sur les infos d'accès aux codes de lancements de missiles nucléaires, ou encore faire un chiffrement à étage pour coder les codes d'accès à une base locale sur une appli mono-utilisateur qui gère les recettes de mamie.
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
Que la force de la puissance soit avec le courage de ta sagesse.
@ fr1man :
ouaip... quelle est la meilleure parade a ca?
@ dinobogan :
le fameux juste millieu...
mais en meme temps je glane de l'info... j'avoue!
le chiffrement a etage, si je peux le comprendre et le mettre en place et qu'il bloque pas l'ordi pour dechiffrer pendant 2 jours... bah en avant...
je suis plutot parti dans l'optique de faire simple en premier lieux et de le complexifier ensuite par plaisir (j'ai du temps libre)
Comme dit, tu peux faire ca et utiliser des choses codées en dures. Cependant si ton appli mérite qu'on s'acharne un peu pour la craquer, des gens le feront, et tout ce qui est codé en dur sera craqué, donc toute ta sécurité...
Un algorithme de cryptage dont la difficulté ne tient qu'au fait qu'on ne connait pas l'algorithme est à proscrire, car n'offre AUCUNE sécurité.
Il n'y a pas de solution miracle à ca.
Ta solution marchera si ton appli ne propose pas un intérêt assez grand pour d'éventuels crackers. si TA bdd contient des données sensibles, alors là il faudra utiliser un moyen sécurisés => intervention humaine, rien en dur.
A toi de nous en dire plus
ok, ca parait assez logique qu'une clef de chiffrement aussi tordue soit-elle ne resiste pas en force brute a nos methode de dechiffrage avec des processeurs aussi puissants que les notres... au bout d'un certain temps...
mais il y a moyen de rendre la chose plus compliquée en y associant l'horloge dans la clef, en augmentant la taille (en octets) de cette clef...
enfin tout ca pour dire que je suppose qu'il existe des croisement de moyen de chiffrements qui rendent juste l'operation pas moins "rentable".
dans mon cas, les données ne sont pas (pour l'instant) critique mais devrais a terme contenir des informations donnant acces a la compta par exemple.
d'ou ma question, existe t'il un "cocktail" de methodes simples a mettre en place qui sans garantir l'inviolabilité me permettrais de commencer ma croisade du chiffrement
Ta clef peut être aussi aléatoire que tu veux (prise en compte de l'horloge d'accès disques, tout ce que tu veux), si tu l'écris en dur, elle est lisible par tout le monde, donc inutile.
Un code ne tient plus si la clef est connue.
Des données pour la comptas sont critiques quand même, il vaut peut-être le coup de rentrer un mot de passe permettant d'ouvrir un keystore et d'extraire une clef privée (par exemple) quand on veut accéder à ces données cryptées. Quand on fait des appli qui gèrent des choses comme ca, un mot de passe ne me parait pas superflu. Après à toi de voir
okay...
je retante un truc
et si l'authentification est gerée par un webservice?
C'est à dire ?
salut, soit tu demande un mot de passe à l'utilisateur (et là, avec de bons algos éprouvés, y a moyen de protéger), soit tu fait tout en automatique. Dans ce dernier cas, moi méchant hacker qui aie envie de connaitre le mot de passe, j'ai juste à lancer TON programme et j'ai accès à la base de donnée -> aucune sécurité autre que la sécurité de la machine locale.
Note que c'est pas spécialement "mauvais" ce dernier cas. Après tout, nombre de serveur ont besoin de mot de passe et on se contente bien souvent de les écrire en clair, dans des fichiers dont l'accès est limité.
Exemples:
mots de passe base de donnée d'un serveur tomcat
mot de passe pour le portefeuille de clés privées ssl d'un serveur httpd apache
etc...
okay okay okay...
donc pour reformuler, si chance qu'une solution il y ai:
comment sécuriser au mieux, SANS mdp utilisateur?
- récupérer le l'authentification ouinedoze (pas évident en java..., je l'ai fais en .net)
- cookie
- webservice d'auth sur un serveur local...
- ...
le mot de passe c'est la merde pour l'utilisateur... et c'est meme pas securisé...
si il n'y a pas une information qui viens de l'utilisateur (directement ou indirectement) n'importe qui disposant du logiciel et du fichier obfusqué peut avoir tous les mots de passes. Si tu prend, par exemple, thunderbird ou firefox, la méthode est la suivante:
création d'un répertoire spécifique à la machine (ceci oblige à avoir un accès local potable pour trouver ce répertoire, ca limite un peu la récupération de données par injection de code, qui hardcodent bien souvent l'appel pour transmettre le contenu d'un fichier). C'est pas la panacée pour autant
"cryptage" des données et stockage de mot de passe dans un fichier séparé
Dans tous les cas, un utilisateur local a accès aux données sans problème.
Ton problème se mort la queue: comment permettre à l'utilisateur d'avoir accès sans mot de passe aux serveurs, tout en ne permettant pas aux gens de lire les tokens d'authentification...
note: tu peux créer un serveur web qui va fournir les tokens d'authentification, serveur web qui utiliserait NTLMv2 pour l'authentification du client (géré coté serveur via JCIFs et coté client par IE)
mais bon, c'est exagérer
note je connais pas à fond JCIFs, il peux peut etre s'authentifier sur un AD où tu récupérerais les tokens
Si je ne m'abuse pour icedove (fork de thunderbird sous debian), il utilise un keystore, protégé par un mdp pour stocker les clefs privées, donc la méthode est sécurisée. Je pense que thunderbird fait de même (ca fait longtemps que j'ai pas eu l'occasion de l'utiliser). Toujours est-il que lorsque je veux signer ou déchiffrer un mail pour la premiére fois de la session il me demande un mot de passe que je suis seul à connaitre qui me permet d'accéder à mon keystore. Bref C'est la seule méthode sécurisée en local : une intervention de l'utilisateur. On ne peut pas se fier aux seuls droits sur les fichiers (surtout sous windows) ou à l'identification de l'utilisateur sur l'ordi, car combien laissent leur session ouverte à tous ?
thunderbird au boulot (mandrake) -> pas de mdp sur le keystore (mais peut etre qu'il me l'avait proposé ^^)
Répondre avec citation
Partager