Discussion :

[Thierry8]

Bonjour,

Je souhaiterais savoir si vous avez des liens javascript ou des méthodes de cryptage en javascript ayant besoin du mot à crypté et d'une clé de cryptage.
Mais aussi de votre avis afin de savoir si cela est sécurisé ?
Il me semble que faire du cryptage avec une clé est la facon la plus sur de protéger lors de la transition les données (ou le mot de passe) non ?

Merci de votre aide.

[Celelibi]

La première chose à savoir c'est : pourquoi cherches tu à chiffrer les mot de passe chez le client avant de les envoyer au serveur ?
La réponse courrante est : pour empêcher la personne de se faire voler son compte si quelqu'un intercepte le mot de passe qui transite sur internet.

Et bien sache que même un chiffrage asymétrique n'empêchera pas l'usurpation d'identité si le mot de passe chiffré est intercepté.
Et ce, simplement parcequ'il suffit de revoyer le même mot de passe chiffré (sans passer par ton formulaire) pour être identifié, et ce sans avoir le mot de passe original.

Si tu veux vraiment empêcher que quelqu'un se fasse voler son compte, utilise plutôt ssl.

Ceci dit si tu veux vraiment utiliser javascript pour chiffrer les mot de passe, on dois facilement trouver des implémentations en javascript du rsa sur internet. Et au pire, ça ne dois pas être bien difficile à coder vu la simplicité de l'algorithme.
Le seul problème étant qu'il faut travailler avec des très grands nombres.

[Thierry8]

N'avez-vous pas de liens, ou doc. sur des alogorithmes...
J'en ai cherché, mais en vain jusqu'à aujourd'hui...

Ma logique:
Formulaire: (3 champs)

Login: moi
Mot de passe: ***
clé (hidden): test

lors de l'envois...
crypter(mot de passe,clé) // le resultat mis dans le mot de passe...
// champ hidden effacé pour l'envois

Donc...après interception la personne aurra toute les peinnes a trouver le bon mots de passe et même s'il elle se ressert du crypt son authentification sera mauvaise ! car la clé change à chaque authentification...

Le seul truc dont je ne suis pas certain, c'est concernant le champ hidden contenant la clé...mais a priori cela laisse beaucoup plus de difficulé au pirate...

PS: je suis preneur pour les algo (ma question première) Merci.

[Celelibi]

Tu peux en trouver plein en cherchant sur google avec les mots clé "rsa" et "javascript".
Par exemple ce site http://www.ohdave.com/rsa/

Le principe d'un chiffrage asymétrique c'est que tu génère une clé privé, et à partir de cette clé privée tu génère une clé publique, et à partir de la clé publique il est quasi impossible de retrouver la clé privé dnas un temps raisonnable.
Donc si tu change la clé publique à chaque identification il faudra aussi changer la clé privée. Et là lors de la soumission du formulaire tu fais comment pour savoir avec quelle clé privé il faut déchiffrer le mot de passe ?
Il ne faut pas oublier non plus que plusieurs personnes peuvent vouloir s'identifier en même temps.
De plus dans le cas du RSA la génération des clés est assez couteuse en ressources. (Il faut trouver des nombres premiers avec au minimum une 10enes de chiffres)

Et au passage, en ce qui concerne la factorisation de grands nombres entiers, on a fait beaucoup de progrès depuis le temps où on testait les divisions.

Et puis dernière chose, n'oublies pas que certaines personnes désactivent le javascript (moi par exemple ).

[Orb Dorb]

Et puis dernière chose, n'oublies pas que certaines personnes désactivent le javascript

Bien dit

Je sais qu'on est dans un forum js mais si tu fonctionnne avec une base de donnée, vas-y avec md5 en php ...
ca se fait côté serveur (ressources côté client moins couteuses) et l'encryption est efficace.
Et pour l'interception des données...
Le résultat est un nombre de 32 caractères hexadécimaux.
Ca lui prend un bon dictionnaire pour déchiffrer le tout.

Bon voilà, fait-en ce que t'en veux...

http://www.php.net/manual/fr/function.md5.php

Bonne recherche

[Celelibi]

En fait je crois que ce qui dérange Thierry8 c'est plus le fait que les mot de passes trnasitent en claire sur internet.
Mais il faut quand même savoir que la réalisation d'une attaque de type man-in-the-middle (MITM pour les intimes ) n'est pas donné à tout le monde. Et quelqu'un qui veut s'en prendre à toi aura sûrement plus vite fait de s'attaquer directement à ton site ou à ton hébergeur que de tenter de récupérer un mdp utilisateur.

Donc je te conseillerais plutôt de chiffrer (ou hasher) les mdp que tu stoque dans ta bdd (endroit où les mdp vont passer plusieurs mois, voir années) plutôt que de les chiffrer durant leur transition sur internet (où leur passage ne dure que quelques milli-secondes).

[denisC]

De toute façon, le cryptage MD5 peut, au besoin (si il redoute réellement une attaque MITM) être fait sur le poste client, avant soumission du formulaire et transit sur internet....

[Thierry8]

Oui pour tout ca je vais aussi prendre mes précautions....Tout est prévus ou presque...

Je m'explique par un exemple:

Formulaire avec 3 champs:

Login: _ _ _ _ _
Mot de passe: * * * *
Cle: * * * * * // hidden

Explication:
Lors de l'envoi pour la protection lors du transit, un cryptage en javascript va prendre la valeur du champ cle et le mot de passe a crypter. Un fois crypter le resultat sera mis dans le champ mot de passe et le champ clé effacé, puis l'envois du formulaire aurra lieu.
Sur le serveur, connaissant la cle, il suffit de décoder le mot de passe.
(à chaque demande d'inscription, une autre clé est générée)
Si quelqu'un récupère le mot de passe crypter et tente de se connecter avec ça ne fonctionnera pas, et il me semble, je dis bien qu'il me semble, que sans la cle il est impossible de decoder le mot de passe même avec un alogo basique !

Pourquoi ne pas hasher lors de l'inscription ?
-> afin de vérifier le mot de passe (longeur minimum - type de caractère)

Formulaire avec 3 champs:

Login: _ _ _ _ _
Mot de passe: * * * *
Cle: * * * * * // hidden

Explication:
Toujours pour assurer un minimum de sécurité lors du transit, lors de l'envois du mot de passe on le hash en md5 (javascript), puis on le crypt à nouveau. Ainsi pour le crypt même avantage que ci-dessus, et si par malheure il décrypte le mot de passe sera hasher. Il pourra donc s'en resservir sur mon site mais ne trouvera pas le mot de passe (en téhorie), ce qui est le but du hash.

---------------------------------------------------------------------------------------------------------------------------------------------------------------
La plus grande faille se trouve peut être lors de l'inscription car il n'est pas hasher pour pouvoir faire des vérification sur le mot de passe.

Pour répondre Celelibi, si tu désactive ton javascript après c'est toi qui sera pénalisé par un manque de sécurité vois tu ?
De plus lorsqu'il s'agit par exemple d'un système comme ci-dessur pour l'administration d'un site, l'administrateur du site à tout interet à l'activer, c'est pour lui. Idem s'il veut inscrire un nouvel admin.

Qu'en pensez-vous ?

[Celelibi]

J'ai une question :
Comment le serveur va faire pour décoder le mot de passe ?
Où sera stoqué la clé privée ? Elle sera sûrement stoqué dans un fichier ou dans une base de donnée. Dans ce cas là, que se passera-t-il si il y a deux inscriptions en même temps ?
Mais bon, imaginons que tu ais résolu ce problème en mettant un champ "id" dans ton formulaire. Ce champ contient un id qui corresspond à un couple clé privé / clé publique dans ta bdd permettant au serveur de retrouver la clé privé et ainsi déchiffrer le mot de passe avant d'effacer les clés de la bdd (elles ne doivent servir qu'une fois).
Tant qu'on est dans les suppositions de MITM, qu'es-ce-qui empêcherais l'attaquant de récupérer la clé publique envoyée à notre utilisateur ?
Il pourrait par la suite récupérer le mot de passe chiffré et factoriser tranquillement la clé publique pour déchiffrer le mot de passe.
Ou alors encore mieux, qu'est-ce-qui empêche notre attaquant de modifier la clé publique envoyé à l'utilisateur ? Il remplace la clé publique par une dont il aura la clé privé corresspondant, il déchiffre le mot de passe avec sa clé privé, puis le rechiffre avec la clé publique que le serveur avait envoyé et remplace le mot de passe chiffré envoyé par celui qu'il vient de créer.
Et là ni le serveur ni le visiteur ne s'est rendu compte que notre Homme-Du-Millieu a récupéré le mot de passe.

Petite modération de mes propos : selon l'attaque MITM il n'est pas toujours possible de modifier les paquets récupérés.

Pourquoi ne pas hasher lors de l'inscription ?
-> afin de vérifier le mot de passe (longeur minimum - type de caractère)

Si tu hash en javascript, autant faire ce type de vérification en javascript non ?


En ce qui concerne l'identification : hasher le mot de passe ne sert strictement à rien !
Supposons que le l'attaquant arrive à déchiffrer le mot de passe (par les méthodes cité pour l'inscription), il va certe récupérer un hash md5, mais ceci est suffisant pour provoquer l'identification.
Si j'ai le hash md5, je vais demander une clé publique au serveur comme si je voulais m'identifier normalement, puis je chiffre le hash md5 en ma possession avec la clé publique envoyé par le serveur, mais sans rehasher le hash.
Le serveur va donc déchiffrer les données envoyés, et trouvera le hash correcte.

Il ne faut pas oublier non plus que générer un couple de clé privée / clé publique qui soit accèptable au niveau de la sécurité est une opération très couteuse en ressources. Il est donc inacceptable de générer un couple de clé à chaque inscription et à chaque identification.
Le chiffrage asymétriqueest fait pour que n'importe qui puisse envoyer des données chiffrés à une même personne, et que le destinataire soit le seul à pouvoir déchiffrer ces données. Le chiffrage asymétrique n'assure pas en lui même que l'expéditeur des données soit bien celui qu'on croit. (pour ça y'a un système de certificats, et encore...)

Je suis sûr à 98% que même sans chiffrer les mots de passe lors de leur transit sur internet, le maillon le plus faible se trouvera au niveau de ton site, voir même directement dans ta gestion de l'identification.
La protection par htaccess est considéré par le plus grand nombre comme étant la méthode d'identification la plus sécurisée. Pourtant les mot de passes sont envoyés en claire. (encodés en base64 en fait)

Pour faire une petite comparaison : tu est en train d'essayer de blinder une porte alors que la fenêtre du 2eme étage est ouverte.

Pour répondre Celelibi, si tu désactive ton javascript après c'est toi qui sera pénalisé par un manque de sécurité vois tu ?

Tout dépend du point de vue où on se place.
J'ai par exemple récemment découvert un bug dans firefox qui permet de le crasher à coup sûr. Il en a existé (et en existera sûrement) d'autres qui permettent une exploitation plus dangeureuse que simplement crasher le navigateur.
Et pour IE n'en parlons même pas, activer JavaScript est tout simplement du suicide.

Je préfère donc désactiver javascript pour entre autre des raisons de sécurité.
Et je dois dire que je me sens bien mieux comme ça, je n'ai par exemple plus les frames de multimania, je n'ai plus les "popin" etc..
C'est moi qui contrôle ma navigation, pas le webmaster par l'intermédiaire de ses scripts.

Dernière chose : il semblerais en plus que chez moi le javascript provoque un memory leak.

[Thierry8]

Comment le serveur va faire pour décoder le mot de passe ?
Où sera stoqué la clé privée ? Elle sera sûrement stoqué dans un fichier ou dans une base de donnée. Dans ce cas là, que se passera-t-il si il y a deux inscription en même temps ?

Session PHP.

En ce qui concerne l'identification : hasher le mot de passe ne sert strictement à rien !
Supposons que le l'attaquant arrive à déchiffrer le mot de passe (par les méthodes cité pour l'inscription), il va certe récupérer un hash md5, mais ceci est suffisant pour provoquer l'identification.

C'est pour cela que je veux crypter...

C'est moi qui contrôle ma navigation, pas le webmaster par l'intermédiaire de ses scripts.

Ici je ne controle pas ta navigation, mais je script simple un champ pour une meilleur sécurité.

Est-ce réellement inutile que de vouloir crypter ?
As-tu des liens qui pourrais m'aider ?

Merci.

[Celelibi]

Désolé, j'ai été trop lent pour éditer mon précédent message, tu as répondu avant qu j'ai fini.

Tu veux stoquer la clé privé dans une session php, mais le problème reste le même :

Tant qu'on est dans les suppositions de MITM, qu'es-ce-qui empêcherais l'attaquant de récupérer la clé publique envoyée à notre utilisateur ?
Il pourrait par la suite récupérer le mot de passe chiffré et factoriser tranquillement la clé publique pour déchiffrer le mot de passe.
Ou alors encore mieux, qu'est-ce-qui empêche notre attaquant de modifier la clé publique envoyé à l'utilisateur ? Il remplace la clé publique par une dont il aura la clé privé corresspondant, il déchiffre le mot de passe avec sa clé privé, puis le rechiffre avec la clé publique que le serveur avait envoyé et remplace le mot de passe chiffré envoyé par celui qu'il vient de créer.
Et là ni le serveur ni le visiteur ne s'est rendu compte que notre Homme-Du-Millieu a récupéré le mot de passe.

C'est pour cela que je veux crypter...

"crypter" n'est pas un mot français, c'est une francisation du mot "cypher" (je crois). Le mot français corresspondant est "chiffrer".
Je préfèrerais que (au moins dans le cadre de notre discution) on utilise le mot "chiffrer" pour ce qui est déchiffrable, et "hasher" pour ce qui est de l'ordre de la génération d'emprunte.

Quand j'ai dit :

En ce qui concerne l'identification : hasher le mot de passe ne sert strictement à rien !
Supposons que le l'attaquant arrive à déchiffrer le mot de passe (par les méthodes cité pour l'inscription), il va certe récupérer un hash md5, mais ceci est suffisant pour provoquer l'identification.

Ce que je voulais dire, c'est simplement que md5 ou pas, si on déchiffre les données qui ont été chiffrés avec la clé publique, on obtiens les données suffisantes pour s'identifier.
Autrement dit :
RSA(md5(passe), clé);
n'apporte absolument rien en terme de sécurité par rapport à :
RSA(pass, clé);

Il ne faut pas oublier non plus que générer un couple de clé privée / clé publique qui soit accèptable au niveau de la sécurité est une opération très couteuse en ressources. Il est donc inacceptable de générer un couple de clé à chaque inscription et à chaque identification.
Le chiffrage asymétrique est fait pour que n'importe qui puisse envoyer des données chiffrés à une même personne, et que le destinataire soit le seul à pouvoir déchiffrer ces données. Le chiffrage asymétrique n'assure pas en lui même que l'expéditeur des données soit bien celui qu'on croit. (pour ça y'a un système de signature/certificats, et encore...)

En claire tu es en train de tenter de réinventer ssl.
Si tu veux des renseignements sur la cryptographie http://fr.wikipedia.org/wiki/Wikip%C3%A9diaortail_Cryptologie

Je te dis, franchement, à moins que les informations transmises soient d'une très haute importance, celui qui sait faire un MITM n'ira pas s'attaquer à ton site.
De plus comme je l'ai déjà dit, tu est en train de renforcer la sécurité là où il y a peu de chance qu'il y ait une attaque, alors qu'il y a sûrement des failles sur ton site même qui permettraient de faire bien plus de choses qu'avec un compte administrateur.

Ici je ne controle pas ta navigation, mais je script simple un champ pour une meilleur sécurité.

Je n'ai pas dis le contraire, j'expliquait simplement pourquoi je désactive le javascript d'une manière générale.