Je suis daccord qu'il faut rester vigilent mais d'autre évenement de ce genre ont révéler par al suite exactement les fuites qu'il y a eu. Donc je ne fait pas une confiance aveugle mais je m'inquiète pas trop non plus.

Pensez-vous que cela peut poser problème?

Non.

Pourquoi?

Car le nom d'utilisateur est transmis en clair dans le paramètre POST user, ainsi il n'y a pas de confusion possible pour le serveur.

Est-ce que l'usage de fonction non injective comme entrée d'une hachage cryptographique peut poser problème en général?

Oui, dans le cas où il n'y aurait pas ce genre de vérification supplèmentaire.

Oui et donc il n'y aura plus correspondant id mot de pass non?

Mouais, j'ai déjà vu ce genre de méthodologie.

Au final, tu ninja le cookie et hop

Tu peux me redire ce que tu entends par "écoute passive" ?

Bonjour

Dans le cadre du boulot, j'ai besoin de mettre en place un système d'authentification, avec BDD de données d'authentification.
Du coup, je repasse sur ce topic, pour m'inspirer des pratiques dans ce domaine

Je comprends donc que dans le cas de l'authentification sur lafibre.info, le serveur stocke dans sa base, les éléments suivants :

• login
• hpw=SHA-1(lower (login) || password)

La phase d'authentification se déroule ainsi :

• 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

Je crois voir plusieurs problèmes :

1- Si une personne vole la base utilisateurs, elle peut s'authentifier en tant que n'importe qui.

En effet, en récupérant SHA-1(lower (login) || password), elle peut dorénavant construire la réponse hash = SHA-1(SHA-1(lower (login) || password) || sid).
En d'autres termes, la propriété 2 énoncée par corrector n'est pas couverte :

2) il ne puisse pas usurper l'identité d'un utilisateur : pour ça, il faut donc que la base ne contienne pas les données qui permettent de s'authentifier auprès du serveur

2- La fonction de hachage est basée sur l'algorithme SHA1.

D'après ce que j'ai lu ailleurs, afin de limiter les risques d'attaques par bruteforce, il est conseillé d'utiliser plutôt des fonctions de hachage "lente", telle que bcrypt.

-> Effectivement, la solution de vivien évite que le mot de passe ne transite, durant la phase authentification.
Cependant, en cas de vol de la base utilisateur, l'attaquant peut faire ce qu'il veut.

Sachant que lafibre.info utilise dorénavant du HTTPS, ne vaudrait-t-il pas mieux que le client envoie carrèment son mot de passe, lors de l'authentification ?
Pour vérifier le mot de passe, le serveur calculerait alors SHA-1(lower (login) || password), et vérifierait que le résultat correspond bien à la valeur stockée.
Dès lors, un vol de SHA-1(lower (login) || password) ne permettrait plus de s'authentifier.

Ais-je bien compris ? Avez-vous des remarques à ce sujet ?