Bonjour tout le mode,
Une idée m'est venue pour le stockage de mots de passe. Je ne suis absolument pas un expert en sécurité, et je me suis donc dit que d'autres personnes l'avaient eue avant moi, mais que comme elle n'était pas répandue, c'est qu'il doit s'agir d'une mauvaise idée.
Alors voilà, on connaît quelques méthodes de stockage des mots de passe, par ordre croissant de sécurité:
- en dur dans le code (!)
- en clair dans une DB
- sous forme de condensat (hash) en utilisant une fonction qui va bien : MD5, SHA1,…
- idem 2., en utilisant une fonction qui va mieux : bcrypt
- idem 3., mais avec un sel ajouté au début du mdp à stocker
- idem 4., mais le sel est différent pour chaque entrée
Tout ceci a prouvé son efficacité, mais –et voilà mon idée– je me demande pourquoi on n'utiliserait pas plutôt des fonctions de chiffrement plutôt que des fonctions de hachage.
Autrement dit: mdp_clair --[chiffrement]--> mdp_chiffré à stocker dans la DB.
Bien sûr, les fonctions de chiffrement symétriques seraient à proscrire, puisqu'on déplacerait le problème vers celui de la sécurité du stockage de la clé, qui doit rester absolument secrète. Mais avec des fonctions de chiffrement asymétriques, on a une clé publique, qui peut être stockée sans précaution particulière. Au passage, on évite à coup sûr le problème des collisions propre aux fonctions de hachage (théorique et très peu probable dans ce contexte, il est vrai), puisque les fonctions de chiffrement sont bijectives.
Voilà, comme je l'ai dit en intro, mon idée n'est sans doute pas une bonne idée, sans quoi elle serait répandue. Je voudrais simplement savoir pourquoi.
# consommateur d'entropie et reversible
Posté par Krunch (site web personnel) . Évalué à 3.
Si on utilise la même clef pour tous les mots de passe, il n'y a qu'une clef à casser/compromettre pour pouvoir déchiffrer tous les mots de passe. Si on utiliser une clef différente à chaque fois, on va consommer pas mal d'entropie à chaque fois.
Si le seul intérêt c'est de diminuer le risque de collision, ça me semble pas une bonne idée.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: consommateur d'entropie et reversible
Posté par Serge Julien . Évalué à 2.
Bien vu, j'étais passé à côté de l'essentiel: les fonctions de hash ne sont pas réversibles. Merci Adrien!
# Ou stockes tu la clé privée?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
Tout est dans le titre :)
[^] # Re: Ou stockes tu la clé privée?
Posté par Serge Julien . Évalué à 2.
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.
[^] # Re: Ou stockes tu la clé privée?
Posté par Jehan (site web personnel, Mastodon) . É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 ]
[^] # Re: Ou stockes tu la clé privée?
Posté par Graveen . Évalué à 2.
Vraiment bien Jehan tes commentaires: accessibles et clairs (les autres aussi, mais là je suis conquis :) )
[^] # Re: Ou stockes tu la clé privée?
Posté par Serge Julien . Évalué à 2.
Merci pour tes explications claires et précises. Je comprends pourquoi mon idée n'est pas bonne. C'était le but de ma question, après tout :)
Sinon en ce qui concerne le sel différent par entrée, c'est à ceci que je pensais et que j'ai déjà vu en pratique: on prend le username, on le fait précéder d'un sel (identique pour chaque entrée et bien sûr non stocké en base, celui-là). On hache le tout avec une fonction "classique" (genre MD5) et le résultat sert de sel pour le hachage du mdp par bcrypt.
# Sha2 + Salt
Posté par Croconux . Évalué à 4. Dernière modification le 25 octobre 2015 à 11:36.
Travaillant dans une boîte devant être certifiée PCI-DSS, je peux parler de ce qu'on a chez nous.
Ne bouge pas, je vais chercher la chevrotine
MD5 est maintenant considéré comme faible et même SHA1 est limite.
Pourquoi pas mais bcrypt est conçu pour être coûteux. C'est à prendre en compte en fonction du nombre de logins.
Tant qu'à introduire un salage autant le rendre aléatoire. Ca évite que des utilisateurs ayant le même mot de passe aient le même hash.
Sinon, chez nous les mots de passe sont stockés hashés en SHA-512 + salt.
[^] # Re: Sha2 + Salt
Posté par Krunch (site web personnel) . Évalué à 7.
Oui, c'est tout l'intérêt. Ça rend les attaques en brut force plus difficile qu'avec des fonction de hashage cryptographiques conçues pour être rapide, tel que SHA-512 par exemple.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Password Hashing Competition
Posté par gouttegd (site web personnel) . Évalué à 3.
Pour information, le concours Password Hashing Competition, qui visait à sélectionner une fonction de condensation de mot de passe (sur le modèle des concours qui ont sélectionné AES et SHA-3), a annoncé cet été avoir choisi l’algorithme Argon2.
Une implémentation de référence est en cours de développement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.