Ou de bien d'autres.
L'une d'entre elles est bien le défi-réponse, sans stocker quoi que ce soit en clair :
Condition de départ : le serveur stocke le mot de passe haché avec ou sans sel. À noter que le sel est forcément stocké localement en clair. Avec cette méthode il sera également transmis en clair (ou à l'intérieur d'une liaison TLS, donc en clair si attaque MITM)
1 - le client fait une demande de connexion en indiquant le nom de connexion
2 - le serveur génère un bloc de données aléatoires, par exemple 1 ko de données, et l'envoie au client. Si sel, il doit être transmis avec le bloc
3 - l'utilisateur tape le mot de passe
4 - le client chiffre le bloc aléatoire avec le mot de passe haché (+ sel éventuel) au moyen d'un algo non réversible
5 - le client génère un sel aléatoire temporaire. Le bloc est re-chiffré avec le mot de passe haché (+ sel éventuel) + le sel temporaire qui vient d'être généré
6 - le client retourne le bloc résultant au serveur + le sel temporaire
7 - le serveur chiffre le bloc d'origine avec le hachage local du mot de passe (+ sel éventuel), le re-chiffre avec le mot de passe + sel éventuel + sel temporaire transmis par le client
8 - le bloc chiffré 2 fois localement doit être le même que celui envoyé par le client
L'étape 5 sert à limiter les possibilités d'Eve (écoute) qui compare les blocs dans les deux sens. Elle limite également les possibilités de Mallory (modifie/génère des blocs) qui construit des blocs spécifiques pour faciliter le recherche du hachage d'origine.
Idéalement il faut que le bloc d'origine intègre des données chiffrées (par le hachage+sel éventuel) que le client pourra ainsi déchiffrer. Par exemple un horodatage + bourrage (le bourrage étant en principe le bloc complet, qui se trouve donc chiffré intégralement). Le client sait déchiffrer cela, et sait alors vérifier que le bloc vient d'être généré. Cela limite beaucoup le rejeu.
[^] # Re: Mot de passe côté serveur
Posté par Kerro . En réponse à la dépêche La sécurité dans le développement. Évalué à 1.
Ou de bien d'autres.
L'une d'entre elles est bien le défi-réponse, sans stocker quoi que ce soit en clair :
Condition de départ : le serveur stocke le mot de passe haché avec ou sans sel. À noter que le sel est forcément stocké localement en clair. Avec cette méthode il sera également transmis en clair (ou à l'intérieur d'une liaison TLS, donc en clair si attaque MITM)
1 - le client fait une demande de connexion en indiquant le nom de connexion
2 - le serveur génère un bloc de données aléatoires, par exemple 1 ko de données, et l'envoie au client. Si sel, il doit être transmis avec le bloc
3 - l'utilisateur tape le mot de passe
4 - le client chiffre le bloc aléatoire avec le mot de passe haché (+ sel éventuel) au moyen d'un algo non réversible
5 - le client génère un sel aléatoire temporaire. Le bloc est re-chiffré avec le mot de passe haché (+ sel éventuel) + le sel temporaire qui vient d'être généré
6 - le client retourne le bloc résultant au serveur + le sel temporaire
7 - le serveur chiffre le bloc d'origine avec le hachage local du mot de passe (+ sel éventuel), le re-chiffre avec le mot de passe + sel éventuel + sel temporaire transmis par le client
8 - le bloc chiffré 2 fois localement doit être le même que celui envoyé par le client
L'étape 5 sert à limiter les possibilités d'Eve (écoute) qui compare les blocs dans les deux sens. Elle limite également les possibilités de Mallory (modifie/génère des blocs) qui construit des blocs spécifiques pour faciliter le recherche du hachage d'origine.
Idéalement il faut que le bloc d'origine intègre des données chiffrées (par le hachage+sel éventuel) que le client pourra ainsi déchiffrer. Par exemple un horodatage + bourrage (le bourrage étant en principe le bloc complet, qui se trouve donc chiffré intégralement). Le client sait déchiffrer cela, et sait alors vérifier que le bloc vient d'être généré. Cela limite beaucoup le rejeu.