Les caractéristiques souhaitables d'un protocole de vérification de mdp sont donc :
- l'écoute passive ne révèle pas un vérificateur de mdp

On voit facilement que cela n'est pas faisable avec de la crypto symétrique uniquement.

On a donc le choix entre des protocoles plus simples qui s'exécutent avec peu de mémoire mais qui exposent le mdp à une attaque par dictionnaire, ou des protocoles plus évolués qui nécessitent de stocker de grands nombres et de travailler dans des corps finis. Ce n'est pas un problème pour un PC (ou une box), mais ça peut être un problème pour certains systèmes "embarqués".

Un nonce (nounce) est un nombre qui n'est généré qu'une seule fois, dans l'Histoire. C'est un grand nombre aléatoire tel que la probabilité de le générer plusieurs fois est négligeable.

On fait des calculs avec cette valeur; le résultat de calcul a forcèment été produit après que le nonce ait été émis, et est lié à ce nonce : le nonce agit comme un identifiant de session.

Je reviens sur les nonces : il faut impérativement qu'ils n'y ai jamais de répétition, et qu'ils soient imprévisibles; pour ça il faut un générateur de nombres pseudo aléatoire de qualité cryptographique.

Il s'agit d'une nécessité absolue. Si les valeurs ne sont pas réellement aléatoires, tout le système s'effondre. Je dis bien tout!

lafibre est en HTTPS, donc est-ce que tu parles du serveur HTTPS ou du serveur HTTP "derrière"?

Les caractéristiques souhaitables d'un protocole de vérification de mdp sont donc :

(clear-pw) aucun mdp ne circule en clair
(pass-ver) l'écoute passive ne révèle pas un vérificateur de mdp
(mitm-ver) une attaque réseau active (MITM) ne révèle pas un vérificateur de mdp
(stor-pw) le serveur ne stocke pas les mdp en clair (ou équivalent clair)
(prot-pw) le serveur n'obtient pas le mdp en clair lors de l'exécution du protocole
(stor-auth) le serveur ne stocke pas un authentifiant
(prot-auth) le serveur n'obtient pas un authentifiant lors de l'exécution du protocole
(slow-verif) l'exécution du vérificateur est lente
(sec-session) le protocole crée une session sécurisée
(no-dos) le serveur ne peut pas être forcé faire des calculs ridiculement lourds (pour éviter le DoS)

La session sécurisée empêche une attaque active une fois que l'authentification a eu lieu : les requêtes sont liées à l'authentification par mdp, si elles sont modifiées elles ne seront plus considérées comme authentifiées.

Si j'ai bien compris le mécanisme d'authentification en place sur lafibre.info (et que celui-ci n'a pas changé depuis le premier post de ce topic) :
- celui-ci possède les caractéristiques (clear-pw), (pass-ver), (mitm-ver), (stor-pw), (prot-pw), (sec-session) et (no-dos).

Si tu parles de ce mécanisme au dessus de HTTP, alors non, il ne fournit pas tout ça.
(clear-pw) oui
(pass-ver) non donc (mitm-ver) sans objet
(stor-pw) oui
(prot-pw) oui
(sec-session) non
(no-dos) oui

- en revanche, celui-ci ne possède pas les caractéristiques (stor-auth), (prot-auth) et (slow-verif).

Exact.

Si j'ai bien compris le mécanisme d'authentification en place sur lafibre.info

Mais fondamentalement cette question n'a pas de sens, parce que le mécanisme dont tu espères qu'il n'a pas changé n'est qu'une page HTML.

(et que celui-ci n'a pas changé depuis le premier post de ce topic) :

Voilà, tu espères que l'implèmentation n'a pas changé.

Donc le mécanisme affiche un formulaire HTML sur une page, donc rien n'indique à l'utilisateur comment ces données seront traitées. Tout ce que l'utilisateur sait est qu'il a une page Web d'un site donné, d'après l'URL. Il doit avoir confiance dans le serveur.

Tu ne saurais pas si le code avait changé, parce que tu n'as rien installé sur ton PC. Il faudrait faire un plugin!

Le vérificateur est une donnée qui permet de tester si un mdp est correct.

J'aurais dû écrire un vérificateur est une fonction de l'ensemble de mdp autorisés vers les booléens indiquant si un pp (password potentiel) est correct.

Je ne vois pas le "vérificateur de mot de passe" transiter en clair dans les échanges :

• Le serveur envoie "sid" aléatoire
• Le client retourne hash = SHA-1(SHA-1(lower (login) || password) || sid)
• Le serveur récalcule hash = SHA-1(hpw || sid), et compare le résultat

En capturant la connexion on peut récupérer :
- login
- sid
- hash = SHA-1(SHA-1(lower (login) || password) || sid)

hash seul n'est pas un vérificateur. Le triplet (login, sid, hash) définit un vérificateur.

La connaissance d'un vérificateur est donc suffisante pour effectuer une attaque par dictionnaire. (Le serveur doit stocker au moins les vérificateurs et pourrait tenter une attaque par dictionnaire.)

En connaissant login et sid, je peux calculer SHA-1(SHA-1(lower (login) || pp) || sid) pour tout pp (password potentiel).

Le vérificateur en fait est la fonction

pp -> ( SHA-1(SHA-1(lower (login) || pp) || sid) == hash )

Ce qui permet de faire une attaque de type dictionnaire ou force brute.