
Envoyé par
Fladnag
Rien n'oblige le pass a être codé de manière réversible. Tu peux très bien garder dans la base une version haché par du md5 qu'il est possible de recoder en JS afin d'obtenir le même hash que ce qu'il y a dans la base. Le jeton envoyé a l'utilisateur n'est pas généré uniquement a partir du pass, mais a partir d'un salt généré a partir de la milliseconde de demande de connexion et d'une combinaison qui d'autre champs (tu peux utiliser le password mais aussi le login par exemple, ou autre, genre le mail, l'age, etc...)
Rien n'oblige à ce qu'il le soit. Mais de toute façon, le sujet n'est pas comment est envoyé le mot de passe, mais comment il est stocké. En l’occurrence, le protocole expliqué pour SPIP est un challenge/response et sans information supplémentaire, il ne permet nullement de déterminer quelle est la méthode de stockage.
Le point intéressant est que tant que le JS n'est pas sécurisé avec une signature numérique ou un contrôle d'intégrité vérifiable cryptographiquement, alors il peut être altéré par un attaquant en coupure, et la sécurité qu'il apporte ne vaut pas plus que du pipi de chat

Après, on peut considérer qu'il s'agit de "défense en profondeur" : si l'attaquant parvient à casser la confidentialité du tunnel TLS, alors il ne verra pas le mot de passe transiter en clair sur le canal TLS.
Ce scénario est absurde car si un attaquant est en mesure de casser la confidentialité de TLS, il est très probablement en mesure de casser également son intégrité...
Donc en résumé :
Cryptographie JS sans TLS : aucun apport de sécurité, zéro-toto.
Cryptographie JS avec TLS : aucun apport de sécurité : TLS fait déjà tout le travail, et avec du code probablement mature, et écrit et/ou vérifié par des cryptographes : intérêt : zéro-toto.
Le seul intérêt que j'entrevois à faire de la crypto en JS, d'une manière générale, est si l'intégrité du script JS est cryptographiquement vérifié et si l'on a besoin de faire de l'AJAX cross-domain avec un tiers qui supporte la crypto dans son code coté-serveur mais que son (mauvais) hébergeur ne supporte pas TLS.
Sinon, aucun intérêt, si ce n'est avoir l'impression de se la toucher.

Envoyé par
Fladnag
Aucun système de sécurité ne protège complètement d'une attaque Man In The Middle. Même quand tu fait de l'https, a moins de forcer l'utilisation de routes TCP/IP différentes lors de l'envoi d'information sur le réseau, ou d'échanger les certificats de manière réellement sécurisée (genre sur une clé USB dans le monde physique), le MITM interceptera l'échange initial avec les certificats et les clés publiques et sera donc en mesure de faire croire a A qu'il discute avec B, et a B qu'il discute avec A en introduisant son propre certificat et en décodant / recodant la requête. Même les autorités de certification se font pirater et il est possible de générer de "faux-vrais" certificats qui ne demandent pas de confirmation a l'utilisateur final... et même avec un certificat envoyé par le MITM non "officiel", la plupart des utilisateurs l'accepterons parce qu'ils n'auront aucun moyen de déterminer facilement que c'est un faux.
Je suis l'auteur de l'article sur la sécurité de PKIX et comment DNSSEC permet d'améliorer cette sécurité, qui est actuellement en kiosque dans le dernier numéro de MISC (n°63).
Je résumerai mon point par : si ton ennemi est une entité (que d'aucuns appelle Men-In-Black) étatique ou mafieuse ayant la capacité de casser une Autorité de Certification ou d'obtenir un CA valide et ayant la créance des navigateurs, ce n'est pas de la crypto JS qui va sauver ton site

Pour tous les autres, TLS tient, et suffit.
Pour ce qui est de l'utilisateur qui valide un certificat invalide : on se trompe de cible : l'objectif d'assurer la confidentialité du mot de passe du client, et son stockage sécurisé est avant tout une obligation de moyen en vue de prévenir toute action en justice contre ton employeur pour faute dans la sécurisation de données personnelles.
Si un utilisateur valide un certificat invalide, d'un point de vue légal, ce n'est pas ton problème, et tu n'es pas en faute. Je ne dis pas que ce n'est pas triste, mais pour ta part, tu as fait tout ce qui était nécessaire pour que ça n'arrive pas, et tu peux difficilement faire plus (à part utiliser HSTS, et le certificate pinning, qui provoque un hard-fail, sous Chrome).

Envoyé par
Fladnag
La solution de SPIP n'est évidemment pas parfaite, mais elle est un bon compromis relativement facile a mettre en place quand tu n'a pas besoin d'un niveau de sécurité digne d'une interface web de lancement de missile nucléaire ;o)
Non, elle est l'exemple typique de l'utilisation de moyens cryptographiques et de sécurité sans avoir fait une étude de risques et compris contre quoi on se battait.
Utiliser un Challenge/Response en JS au travers de HTTP dans l'objectif de sécuriser un mot de passe est d'une inutilité flagrante en terme de sécurité et d'une dangerosité patente pour la disponibilité du service car elle complexifie sans le moindre intérêt le mécanisme. Cela le rend donc plus difficile à comprendre, et à déboguer sans aucun apport en échange.
En un mot : KISS.

Envoyé par
Fladnag
Après on peux aussi se demander l’intérêt de crypter des échanges quand on sait que la majorité des serveurs mails autorisent l'envoi des mots de passe mail en clair, mais c'est un autre débat...
Autre débat, mais oui,et l'énoncé n'est pas clair : si on parle de mots de passe d'accès aux sites, alors c'est effectivement à bannir : un mot de passe ne devrait JAMAIS être envoyé par email.
Si on parle des mots de passe d'accès aux boites emails, ce qui est absurde, c'est surtout que la plupart des clients emails qui implémentent TLS l'implémentent très mal, ce qui fait qu'on peut de toute façon faire une attaque de type MITM et intercepter le mot de passe quand même.
Pour ma part, l'accès à mes boites emails se fait par authentification TLS mutuelle, ce qui coupe les jambes aux attaquants : il y a pas de mot de passe du tout... hélas, cela signifie que je suis très limité dans le choix de mes clients emails =)
1 |
0 |