Je n'en ai pas besoin: je vérifie si le résultat du chiffrement par la clé publique du mdp saisi est égal à la valeur chiffrée stockée en base.
J'ai du mal à comprendre. En gros, tu crées un couple clé publique/privée, tu jettes la clé privée, et tu te contentes de vérifier que le mot de passe entré par l'utilisateur avec la clé publique est le même que celle dans ta BDD? C'est juste une fonction de hashage que tu recrées donc (avec la différence qu'elle est réversible comme quelqu'un le note plus haut, sauf que tu n'en as pas la clé, mais ça ne veut pas dire que quelqu'un ne peut parvenir à la recréer, tu perds donc potentiellement en sécurité même).
Sinon le problème des collisions n'en est pas vraiment un car tu stockes un hash par utilisateur. Donc oui dans la théorie, différents utilisateurs pourraient avoir le même hash avec en fait des mots de passe différents. Mais dans l'éventualité très très improbable que cela arriverait, cela ne poserait aucun problème dans ce cas précis (identification). Tous les utilisateurs arriveraient toujours à se logguer avec leurs mots de passe.
La collision des hashs n'est un problème que lorsque des besoins de comparaisons sont nécessaires (tu n'as pas besoin de comparer les hashs d'utilisateurs, d'ailleurs plusieurs utilisateurs ont aussi le droit d'avoir le même mdp). Par exemple c'est un problème "potentiel" pour des hashs publiques, comme lorsqu'utilisés dans une adresse web, cas assez courant quand des adresses sont générés, souvent par exemple on a vu ça dans les hébergeurs divers (images, vidéos, avatars, clouds, etc.); ou bien des hashs de commits de version de source code, etc. Enregistrer des hashs de mot de passe? Aucun problème en vue.
Enfin au sujet du sel différent par entrée: où le stockes-tu? L'un des avantages majeurs du sel est que tu le stockes sur un support différent que les hashs. En l'occurrence le sel est souvent dans les fichiers de config du serveur, dans un simple fichier alors que les mots de passe sont en BDD (en général déporté sur d'autres serveurs dans le cas de gros services). L'idée est que beaucoup d'attaques ne parviennent qu'à récupérer une partie des données, en l'occurrence souvent le contenu de la base de données "uniquement" (par exemple avec une injection SQL dans un site web), mais pas les fichiers sur le serveur. Donc l'attaquant se retrouve avec des hashs faits avec un sel inconnu rendant sa tâche plus difficile.
Si tu as un sel par entrée, tu vas en général le stocker sous forme de BDD, et si tu les stockes dans la même base de données, alors l'attaquant y a accès en s'emparant de la base de donnée et c'est donc inutile (équivalent à hash non-salé). Donc si "théoriquement" ce que tu dis est vrai: avoir un sel par entrée serait plus sûr, faut vraiment voir comment cela est fait. Si le sel est stocké dans la même BDD, alors (6) est au contraire moins sûr que (5).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ou stockes tu la clé privée?
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Y a-t-il des cryptographes dans la salle? Stockage de mots de passe. Évalué à 8.
J'ai du mal à comprendre. En gros, tu crées un couple clé publique/privée, tu jettes la clé privée, et tu te contentes de vérifier que le mot de passe entré par l'utilisateur avec la clé publique est le même que celle dans ta BDD? C'est juste une fonction de hashage que tu recrées donc (avec la différence qu'elle est réversible comme quelqu'un le note plus haut, sauf que tu n'en as pas la clé, mais ça ne veut pas dire que quelqu'un ne peut parvenir à la recréer, tu perds donc potentiellement en sécurité même).
Sinon le problème des collisions n'en est pas vraiment un car tu stockes un hash par utilisateur. Donc oui dans la théorie, différents utilisateurs pourraient avoir le même hash avec en fait des mots de passe différents. Mais dans l'éventualité très très improbable que cela arriverait, cela ne poserait aucun problème dans ce cas précis (identification). Tous les utilisateurs arriveraient toujours à se logguer avec leurs mots de passe.
La collision des hashs n'est un problème que lorsque des besoins de comparaisons sont nécessaires (tu n'as pas besoin de comparer les hashs d'utilisateurs, d'ailleurs plusieurs utilisateurs ont aussi le droit d'avoir le même mdp). Par exemple c'est un problème "potentiel" pour des hashs publiques, comme lorsqu'utilisés dans une adresse web, cas assez courant quand des adresses sont générés, souvent par exemple on a vu ça dans les hébergeurs divers (images, vidéos, avatars, clouds, etc.); ou bien des hashs de commits de version de source code, etc. Enregistrer des hashs de mot de passe? Aucun problème en vue.
Enfin au sujet du sel différent par entrée: où le stockes-tu? L'un des avantages majeurs du sel est que tu le stockes sur un support différent que les hashs. En l'occurrence le sel est souvent dans les fichiers de config du serveur, dans un simple fichier alors que les mots de passe sont en BDD (en général déporté sur d'autres serveurs dans le cas de gros services). L'idée est que beaucoup d'attaques ne parviennent qu'à récupérer une partie des données, en l'occurrence souvent le contenu de la base de données "uniquement" (par exemple avec une injection SQL dans un site web), mais pas les fichiers sur le serveur. Donc l'attaquant se retrouve avec des hashs faits avec un sel inconnu rendant sa tâche plus difficile.
Si tu as un sel par entrée, tu vas en général le stocker sous forme de BDD, et si tu les stockes dans la même base de données, alors l'attaquant y a accès en s'emparant de la base de donnée et c'est donc inutile (équivalent à hash non-salé). Donc si "théoriquement" ce que tu dis est vrai: avoir un sel par entrée serait plus sûr, faut vraiment voir comment cela est fait. Si le sel est stocké dans la même BDD, alors (6) est au contraire moins sûr que (5).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]