Guide : Stocker des mots de passe de manière sécurisée

J'espère que toutes les fuites de données de ces dernières années ont laissé une empreinte indélébile dans l'esprit des développeurs : Ne jamais stocker des mots de passe en clair dans une base de données. Jamais.

Une fois ce rappel obligatoire fait, nous pouvons passer au cœur du problème, à savoir : quelles sont les bonnes pratiques pour stocker les mots de passe de vos utilisateurs ?

Tout d'abord, vous devez vous mettre en tête que peu importe la taille de votre site, un attaquant sera éventuellement capable de :

• Récupérer les informations de votre base de données
• Avoir accès au code source du serveur
• Automatiser des actions pour essayer de s'introduire

Bien sûr, votre objectif est de tout faire pour éviter que cela arrive, mais il faut que vous gardiez ces informations en tête lors de la conception de votre système de mots de passe.

Communiquer en https

La première étape est de sécuriser votre site web (ou votre application) en forçant la communication par https car lors de l'inscription ou de la connexion, le mot de passe de votre utilisateur sera envoyé en clair dans la requête.

Pour éviter tout problème d'interception des données, assurez vous que le chiffrement de ces données soit effectué grâce à un certificat SSL, c'est la première étape de sécurisation du mot de passe.

Hashage

Une fois arrivé sur le serveur, le mot de passe devra être "hashé" avant d'être sauvegardé en base de données. Attention, on ne chiffre (encrypte) pas le mot de passe, mais on le hash, les deux notions sont complètement différentes.

Une donnée chiffrée doit pouvoir être déchiffrée grâce à la clé de chiffrement utilisée et l'on doit pouvoir retrouver l'information originelle intacte, les méthodes de hashages sont dites "destructives".

Si vous n'êtes pas familier avec les hashs, je vous invite à lire mon article dédié juste en dessous !

Si vous voulez aller encore plus loin, il y a un très bon article sur le blog de Auth0 que je vous recommande !

Grain de sel

À première vue, lorsque vos mots de passe sont hashés avec un algorithme suffisamment sécurisé, même si votre base de données subit une fuite, les attaquants n'auront pas directement accès aux mots passe de clairs.

Mais si ces dernier arrivent à découvrir quel algorithme de hashage a été utilisé (ce qui est possible), il leur reste quand même la possibilité de générer des mots de passe et de les comparer aux hashs trouvés en utilisant des techniques comme  :

• Le brut-force: Tester toutes les possibilités de suites de caractères différents
• Les dictionnaires : Tester des combinaisons de mots issus des informations personnels et de mots usuels

Certains attaquants utilisent même ce qu'on appelle des "rainbow-table", d'immenses tableaux de hashs déjà générés (avec les méthodes ci-dessus) avec l'algorithme de hashage trouvé précédemment, ces tableaux peuvent parfois peser jusqu'à plusieurs Tera-octets.

Pour freiner (voir empêcher) ces attaques, on utilise la méthode du grain de sel (ou du salage) qui consiste à ajouter une chaine de caractères au mot de passe avant qu'il ne soit hashé.

Ce grain de sel permet de rallonger la taille du mot de passe de base (et donc de le rendre plus long à craquer, car plus long à générer), et de limiter l'utilisation de dictionnaires et des rainbow-tables.

Statique

Le salage statique consiste à ajouter toujours la même chaine de caractères pour tous les mots de passe enregistrés, ce grain de sel doit rester secret, car sinon son efficacité est corrompue.

Cette technique permet de ralentir la récupération des mots de passe, mais elle n'empêche pas l'utilisation de rainbow-tables, ces dernières devront simplement être générées spécifiquement pour ce site en particulier.

Dynamique

Le salage dynamique consiste à générer aléatoirement un grain de sel pour chaque utilisateur, et de le stocker en plus du mot de passe dans la base de donnée (ou au mieux dans une base de donnée séparée).

Cette technique vise notamment à empêcher l'utilisation d'une rainbow-table sur l'entièreté de la base de données, car chaque utilisateur ayant un grain de sel différent, il est impossible de pré-calculer tous les hashs pour tous les grains de sels possibles.