Bon, tout le monde devrait le savoir, même si mon expérience récente me montre qu’un rappel n’est pas inutile :
- On ne stocke pas les mots de passe en clair, on les crypte
- On n’utilise pas un chiffrement réversible mais une fonction de hachage
- Un simple hachage ne suffit pas, il faut y ajouter un salage
- Le salage doit être différent pour chaque mot de passe
- L’algorithme utilisé doit être lent, comme blowfish par exemple
Croyez moi, j’ai encore découvert il y a peu que non seulement ce n’était pas évident pour tout le monde mais que certains refusent de considérer un simple stockage sous forme md5 sans salage comme une erreur et un problème potentiel de sécurité.
Mais plus que tout ça, pour moi la règle de base c’est « ne jouez pas avec la sécurité ». Si vous n’êtes pas un expert dans la question : ne créez rien et n’implémentez rien vous-même, utilisez des bibliothèques de codes toutes faites.
Et par pitié, ne tentez pas d’améliorer les choses
En jouant sur l’intuition, vous avez toutes les chances d’arriver à un résultat opposé à celui que vous espérez.
Dans le texte du jour à lire, Properly Salting Passwords, The Case Against Pepper, nous avons un superbe exemple que je tente d’expliquer en vain à chaque fois qu’on lève le sujet :
Pour « améliorer » la sécurité, en plus du salage géré par l’algorithme, propre à chaque mot de passe, certains cherchent à ajouter un second salage, global à l’application. L’idée est que le salage présent à côté du mot de passe dans la base de données ne suffit pas, il faudrait en plus connaitre le salage global utilisé par l’applicatif, et donc profiter d’une faille de sécurité plus importante afin d’exploiter quoi que ce soit.
L’idée semble bonne, intuitivement. Malheureusement vous n’êtes probablement pas un expert sur l’algorithme blowfish. Vous ne *savez* pas si ajouter le même salage en début ou en fin du mot de passe avant de l’envoyer à blowfish ne risque pas de réduire la sécurité du résultat. Oh, vous avez probablement l’intuition que ce n’est pas le cas, voire vous en êtes certains, mais aucune documentation de sécurité reconnue comme étant d’autorité ne le précise explicitement.
Vous en êtes à l’intuition et vous avez une chance sur deux de vous planter. Au final, est-ce vraiment un bon pari ? Ça pourrait l’être si l’état de l’art du stockage des mots de passe était franchement insuffisant et s’il n’y avait aucune méthode standard pour l’améliorer. Ici il est probable que vous ne soyez pas encore à l’état de l’art (n’utiliseriez-vous pas sha1 ou md5 ?) et cet état de l’art est probablement suffisant si vous utilisez suffisamment d’itérations.
Mais plus que cette question du double salage, qui est une mauvaise idée pour ce que vous et moi en savons, c’est toute l’implémentation que vous ne devriez pas toucher. Utilisez une bibliothèque de code éprouvée, ou mieux : une fonction prévue pour. En PHP nous avons « crypt », qui avec avec l’algorithme blowfish et suffisamment d’itérations, rendra votre stockage des mots de passe bien plus solide que tout le reste de votre application.
Laisser un commentaire