• [^] # Re: Fin du hachage du mot de passe?

    Posté par . En réponse à la dépêche SPIP le CMS qui tient ses promesses. Évalué à 3.

    Je ne sais pas précisément comment marchait l'authentification, mais l'expérience montre qu'un certains nombre de développeurs raisonnent de la façon suivante :

    • je veux que les utilisateurs s'authentifient en HTTP
    • mais si j'envoie le mot de passe en clair, n'importe quel intermédiaire peut voler le mot de passe
    • donc je vais être malin et hacher le mot de passe m avec une fonction à sens unique h sur le client, puis envoyer h(m), comme cela le mot de passe ne circulera pas en clair.

    Ça paraît malin, sauf que...

    • pour s'authentifier auprès du serveur, il n'y a plus besoin du mot de passe m, juste de la valeur de h(m)
    • et ça tombe bien pour l'homme du milieu qui va voir passer cette valeur
    • il lui suffit donc d'écrire son propre client qui enverra cette valeur (sans avoir besoin de connaître m)

    Résultat : on n'a rien gagné en sécurité.

    Il y a évidemment des protocoles plus complexes qui permettent de s'authentifier sur un canal qui est espionné. Mais à ma connaissance, pour résister à un adversaire passif, ils demandent de partager un secret (ce qui veut dire stocker le secret sur le serveur) ou... reposent sur de la crypto à clé publique (type échange de Diffie-Hellman). Et si on veut résister à un adversaire actif, il faut rajouter une forme de PKI (certificats).

    TL;DR: il y a un protocole qui permet d'échanger sur un canal non-sûr, ça s'appelle TLS.