[mOved] C# crypter des mots de passe pour les stocker dans une BDD XML - Page 1

Hello,
Je dois stocker des mots de passe dans un fichier XML. OK, ça part mal, mais ce ne sont pas des données "très sensibles".
Comme c'est du XML, le minimum, c'est bien sûr de les crypter.
J'ai bien réflechis à quelques algos "fait main", mais après quelques lectures sur le sujet, je me rend compte que je n'ai rien inventé, et que ce n'est pas "secure" :
Factorisaton du code avec un autre mot, décallage quelconque, grilles aléatoires, autand dire le B-A-BA.
Je ne sais pas vers quelle technologie ou algorithme utiliser, puisque je n'ai jamais été confronté à ce problème.
Vous auriez des suggestions, svp?
Merci d'avance.

GUNNM (./1) :
Hello,
Je dois stocker des mots de passe dans un fichier XML. OK, ça part mal, mais ce ne sont pas des données "très sensibles".
Comme c'est du XML, le minimum, c'est bien sûr de les crypter.
J'ai bien réflechis à quelques algos "fait main", mais après quelques lectures sur le sujet, je me rend compte que je n'ai rien inventé, et que ce n'est pas "secure" :
Factorisaton du code avec un autre mot, décallage quelconque, grilles aléatoires, autand dire le B-A-BA.
Je ne sais pas vers quelle technologie ou algorithme utiliser, puisque je n'ai jamais été confronté à ce problème.
Vous auriez des suggestions, svp?
Merci d'avance.

Tu doit pouvoir retrouver le mot de passe ?

Ou tu a juste besoin de verifier si la personne tape le bon ?

Si c'est juste pour vérifier, plutot que crypter, mieux vaut hasher le mdp avec un algo genre MD5/SHA1 & co et stoquer la valeur de hash...

Martial Demolins (./4) :
Et c'est pas safe à 100%

Ben ça c'est vrai pour tout système de crypto (à part le one-time-pad), et d'autant plus pour les fonctions de hachage

Si tu utilises un truc à base de hachage, pense à utiliser une salt value, ça rend le système plus difficile à casser.

Martial Demolins (./4) :
Et c'est pas safe à 100%

Heu, va trouver un MDP hashé en SHA1 :/

Si tu veux on peut tester

voila un mot de passe hashé en SHA1


f224932926037cd8e6608adc7d23d98d76e15160


Bon courage

http://msdn.microsoft.com/en-us/library/system.security.cryptography.md5cryptoserviceprovider.aspx ou http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha1cryptoserviceprovider.aspx au choix

apres suffit de stocker ca en base64 et hop

^^

./6 : http://www.freerainbowtables.com/ & consors ?

Ne fait pas le SHA1 et (je teste pour le MD5)

Mais bon je doute qu'il trouve le passe en question mais on verra

rednoize faut le sha1, et ca fait qq annees que les outils le font quand meme...

Oui et il faut combien de temps en moyenne ?

(je viens de lancer pour le mot de passe cité plus haut hashé en MD5 pour voir combien de temps il faudra que le projet distribué, on verra bien combien de temps il faut...)

Heu des collisions il y en a en MD5 mais c'est rare, mais j'ai pas encore entendu de telle histoires pour le SHA1 (j'ai peu être quelques pages de retard mais bon)

Il y a des collisions évidemment, tu ne peux pas faire une application injective d'un ensemble de cardinalité n à un ensemble de cardinalité m avec m<n. L'essentiel est que ces collisions ne soient pas évidentes à trouver, c'est ça un hash robuste contre les collisions.

godzil: "le font" ca veut dire qu'il existe des bdd de sha1 si tu preferes, pas simplement des bruteforce

Kevin Kofler (./14) :
Il y a des collisions évidemment, tu ne peux pas faire une application injective d'un ensemble de cardinalité n à un ensemble de cardinalité m avec m<n. L'essentiel est que ces collisions ne soient pas évidentes à trouver, c'est ça un hash robuste contre les collisions.

Si tu prefere, je n'ai pas encore entendu parlé de collision volontaire pour le SHA1, contrairement au MD5

Beh pourtant y'en a aussi hein... tapes "sha1 collisions" sur google tu vas surement trouver pas mal de trucs

Non, pas pour la fonction complète (80 rounds) même si on en est pas très loin, et pas pour SHA-256 & co qui sont pas mal plus sûres... Et puis avec un salt on sait pas faire même pour MD5 je crois.

De toute façon la possibilité de créer des collisions n'a aucune incidence sur la sécurité en tant que mot de passe : pour générer une collision entre les mdp de deux utilisateurs il faudrait que ces deux utilisateurs se mettent d'accord et donc soient consentants à avoir le même hash

tiens, schneier en parlait:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

Voilà, c'est une attaque théorique qui n'a pas encore débouché sur une collision concrète.

Ben non justement, on ne sait générer une collision que si tous les deux on se met d'accord pour mettre certains mots de passe : même si je te disais que mon mot de passe c'est "toto", tu n'as aucun moyen de créer une collision : pour créer une collision, il faut que tu me dises (et que j'accepte) de modifier mon mdp pour qu'il soit de la forme "toto84c0553a87957ceecf8d3b07a0bc226f", et alors il y aura une collision avec ton mot de passe "supermartial48ad7176dc33521c51d17a24eb6141fe". Si je refuse de modifier mon mot de passe il ne sera en collision avec rien du tout

(sinon oui ça peut arriver par pur hasard, mais même si toute l'humanité changeait de mot de passe 1000 fois par jour il n'y aurait une collision qu'au bout de 10000 ans [et elle ne concernerait que qqun mort il y a 9900 ans et qui a changé son mot de passe au moins 3 millions de fois après la collision ^^])

Merci pour vos réponses.
Desolé de ne pas avoir répondu, j'étais absent, je lis tout ça et je reviens.

Martial > GPG je ne connais pas, je vais me renseigner.
Godzil > Oui l'appli doit retrouver le MDP car c'est un MDP de connexion à une BDD dont l'appli a besoin.

Idéalement j'utiliserais un truc tout fait, mais si je dois coder un algo, pourquoi pas, si vous avez des pistes.

Je préfèrerais éviter le MD5 à cause des dictionnaires de mot en MD5 dispo sur le net, même si "théoriquement" le MDP sera plus compliqué qu'un mot.
Je cherche un truc simple à mettre en oeuvre, donc je ne reste pas fermé au MD5 non plus.

nan, mais si tu dois stocker pour pouvoir le retrouver, un hash ca va pas du tout... il te faut de l'encryption la:
!google AES/DES

J'ai pris AES qui est facile à mettre en place, merci nEUrOO.

De toute manière tout est crackable directement par la NSA :P Vu qu'ils contrôlent les spec de sortie..

pas de tout

bein disons que 99% des softs viennent des US et qu'il y a une loi aux US sur la limitation de l'exportation des logiciels de cryptographie etc... on va dire presque tout.
Il suffit de voir l'affaire XP avec 2 clés de mise à jour, une pour microsoft, une pour la NSA.

Sinon donne moi un exemple

Y'a quand même pas mal de chercheurs indépendants qui étudient les algos publics de crypto, donc s'ils y a des faiblesses dedans, faut que ce soit fait très subtilement

Après ils peuvent toujours mentir sur la longueur de clé qu'on peut considérer comme sûre, vu qu'on ne sait pas de quelle puissance de calcul ils disposent vraiment

Zerosquare (./29) :
Après ils peuvent toujours mentir sur la longueur de clé qu'on peut considérer comme sûre, vu qu'on ne sait pas de quelle puissance de calcul ils disposent vraiment

bah il y a quand même des labo hors US qui traitent de la sécurité, donc a moins qu'ils soit aussi dans le complot si il y avait tant de risque ça se saurait