Discussion :

[grunk]

Ce qu'il ne faut pas lire quand même... la cryptographie, ça ne s'improvise pas. Je recommande la lecture de "Applied Cryptography" et de "Secret and Lies" de Schneier pour éviter de raconter des bêtises à ce sujet

On est quand même d'accord sur le fait que md5 et sha sont vulnérables à cause des tables de comparaison (combien d'utiilisateur n'utilise pas un mot de passe "simple" ?) qu'on trouve partout et de leur risque de collision ?

[X_Cli]

On est quand même d'accord sur le fait que md5 et sha sont vulnérables à cause des tables de comparaison (combien d'utiilisateur n'utilise pas un mot de passe "simple" ?) qu'on trouve partout et de leur risque de collision ?

Non, ce qui est vuln, c'est d'utiliser des sels très courts, comme "b9" ou autre. Mais si on fournit un salt avec ne serait ce que 4 octets complètement aléatoires (2^32 valeurs), ca fait 4 milliards de rainbow table à générer pour avoir des "dicos" précalculés. Improbable.


Par ailleurs, il y a des rainbow aussi pour les autres algo...

[grunk]

Non, ce qui est vuln, c'est d'utiliser des sels très courts, comme "b9" ou autre. Mais si on fournit un salt avec ne serait ce que 4 octets complètement aléatoires (2^32 valeurs), ca fait 4 milliards de rainbow table à générer pour avoir des "dicos" précalculés. Improbable.


Par ailleurs, il y a des rainbow aussi pour les autres algo...

Je parlais d'une utilisation sans grain de sel , comme on le trouve dans la majorité des cas , hélas.

[Fladnag]

Hacher le mot de passe coté client est inutile : le secret n'est plus le mot de passe, mais son condensat : apport en capacité d'authentification : zéro-toto.

Je ne serais pas aussi catégorique.
Si tu hache le pass avant l'envoi coté client AVEC un salt fourni par le serveur (unique par client, et unique par demande de connexion), comme le système d'authentification de SPIP, tu fait circuler sur le réseau un hash qui n'est valable que pour un utilisateur et surtout une seule utilisation.

[X_Cli]

@grunk: dans ce cas, ce ne sont pas les algos qui sont en tort mais leur mise en oeuvre.

@Fladnag: l'algo que tu décris est une authentification par challenge/response : ce n'est pas un salt mais un nonce qui est envoyé. En l'occurence, cela ne dit rien sur la façon dont est stocké le mot de passe dans la base : si le token est généré par le hachage du mot de passe avec le nonce, alors le mot de passe doit carrément être stocké en clair ou de manière réversible dans la base. Vu l'historique de sécurité de SPIP, ca m'inquièterait, mais ne m'étonnerait pas.
De plus, cette authentification est parfaitement inutile, et est juste l'expression déraisonnable de geeks du Javascript : au travers de Https, un tel mécanisme est parfaitement superflu, puisque la confidentialité est déjà assurée par TLS. Si cela transiste à travers HTTP, alors le JS qui effectue le traitement n'est pas garanti fiable : il peut avoir été altéré par un attaquant en position de faire un Man In The Middle (le même qui écoute le mot de passe en clair quand il transite ainsi), et par exemple exfiltrer le mot de passe avant son utilisation dans la génération du condensat.

En un mot: TLS.
En plus de mots : suivez la formation SANS Dev522 (Web Application Security Essentials), qui détaille tous ces problèmes très bien (ce n'est pas de la pub, il y a plusieurs centres de formation)

[Fladnag]

En l'occurence, cela ne dit rien sur la façon dont est stocké le mot de passe dans la base : si le token est généré par le hachage du mot de passe avec le nonce, alors le mot de passe doit carrément être stocké en clair ou de manière réversible dans la base.

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...)

De plus, cette authentification est parfaitement inutile, et est juste l'expression déraisonnable de geeks du Javascript : au travers de Https, un tel mécanisme est parfaitement superflu, puisque la confidentialité est déjà assurée par TLS. Si cela transiste à travers HTTP, alors le JS qui effectue le traitement n'est pas garanti fiable : il peut avoir été altéré par un attaquant en position de faire un Man In The Middle (le même qui écoute le mot de passe en clair quand il transite ainsi), et par exemple exfiltrer le mot de passe avant son utilisation dans la génération du condensat.

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.

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)

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...

[X_Cli]

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.

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).

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.

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 =)