Stockage de mots de passe : le sel c'est bon pour le coeur

On entend parler régulièrement de fuites de données, en particulier de mots de passe. Le problème est assez important, puisqu'on sait tous que la majorité des gens réutilisent leurs mots de passe sur différents services. Du coup, il ne faut JAMAIS stocker des mots de passe en clair dans une base de données. Partez du principe que votre base de données fuitera, et protégez vos données sensibles en conséquence.

Quelques généralités

Pour stocker des mots de passe, on utilise en gros trois techniques différentes :

Le chiffrement symétrique

(Pitié ne parlez pas de cryptage)

Le chiffrement symétrique est une technique qui permet de transformer un message (le clair) en un message incompréhensible (le chiffré) à l'aide d'une clef (une phrase de pass généralement), et de retransformer le chiffré en clair à l'aide de la même clef (d'où le terme symétrique). C'est donc une procédure réversible.

Le hachage

Le hachage d'une donnée est une suite de traitements permettant d'obtenir un hash (ou condensat) propre à cette donnée, qui est une valeur courte et simple à comparer. L'intérêt du hachage est qu'il est non réversible : on ne peut pas calculer la donnée à partir de son condensat. Il faut donc calculer le hash du mot de passe saisi par l'utilisateur au hash stocké en base. Un bon algorithme de hachage permet de limiter les risques de collision (deux données différentes ayant le même hash), donc si les condensats sont identiques, il est raisonnable de supposer que les mot de passe le sont aussi.

Le salage

Le hachage est la méthode la plus courante, elle permet de remplacer un mot de passe en clair par un condensat dans la base de données. Toutefois, il existe ce qu'on appelle des "rainbow tables", des tables de correspondance entre des mots et leur hash, ce qui permet de retrouver la donnée à partir de son hash. L'ajout de sel (salt), une petite chaîne de caractères, permet de modifier le hash et donc de rendre les rainbow tables inutiles, à moins que l'attaquant n'en refasse une incluant le sel.

C'est bien beau tout ça, mais comment on s'y prend, concrètement ?

Suggestion raisonnable

Le format fiable le plus courant est l'utilisation d'un algorithme de hachage solide (SHA256 ou SHA512 par exemple) doublé d'un sel propre à chaque utilisateur. Le sel est stocké en clair dans la base de données, on peut alors se demander quel intérêt pour la sécurité. C'est simple : chaque utilisateur ayant un sel différent, un attaquant devra recalculer une rainbow table pour chaque utilisateur avant de tenter de casser son mot de passe. On ne s'appuie donc pas sur le secret mais sur le manque de rentabilité par rapport au temps passé pour casser le hash.

Suggestion plus... brutale

Dropbox possède des données sensibles de milliers d'utilisateurs et d'entreprises dans ses serveurs, ce qui motive un peu plus d'investissement pour tenter de casser les mots de passe. Ils ont donc mis en place un système plus solide, expliqué dans un article de blog bien détaillé. Et franchement, niveau sécu, on est pas mal : ils ont joué aux poupées russes. En multipliant les couches de sécurisation différentes (chiffrement et hachage), ils ont mis en place un modèle qui se veut le plus résistant possible pour éviter la récupération de mots de passe en cas de fuite de données.

Conclusion

Quelle que soit la sensibilité des données que vous hébergez, il n'est aujourd'hui pas raisonnable de stocker des mots de passe en clair, ou même hachés sans sel. (J'ai l'impression de faire un blog cuisine là...)

Un conseil que certains chez Yahoo ou LinkedIn auraient aimé recevoir...