Salut, c'est Nico de Code Garage.
Code Garage, qu'est-ce que c'est ? C'est un site avec des ressources gratuites pour
les développeurs et les développeuses qui souhaitent s'améliorer et passer de juniors
à experts, mais aussi des formations pour s'améliorer encore plus vite.
Aujourd'hui, dans ce nouvel épisode du podcast, on va parler du stockage de mots de passe
et comment stocker des mots de passe de manière sécurisée.
Je pense qu'avec les fuites de données des dernières années, ça a laissé une empreinte
indélébile dans l'esprit des devs.
Évidemment, ne jamais stocker de mots de passe en clair dans une base de données, ça,
c'est vraiment la règle d'or.
Mais une fois que ce rappel a été fait, il faut passer au cœur du problème.
En réalité, c'est quoi les bonnes pratiques pour stocker les mots de passe de vos utilisateurs ?
Pour commencer, il faut se mettre en tête que peu importe la taille de votre site, un
attaquant sera éventuellement capable de soit récupérer les informations de votre base
de données, avoir accès aux codes sources de votre serveur ou juste automatiser des actions
pour essayer de s'introduire.
Évidemment, votre objectif premier, c'est de tout faire pour éviter que ça arrive,
mais il faut que vous gardiez ces informations en tête pendant la conception de votre système
de mots de passe.
La première étape, c'est de sécuriser votre site ou votre application en forçant
la communication par HTTPS.
Parce que lors de l'inscription ou de la connexion, le mot de passe de votre utilisateur, il sera
envoyé en clair dans la requête.
Donc pour éviter tout problème d'interception des données, il faut s'assurer que le chiffrement
de ces données soit effectué grâce à un certificat SSL.
La deuxième étape, c'est le HH.
Le HH, c'est qu'une fois arrivé sur votre serveur, le mot de passe, il devrait être
acheté avant d'être sauvegardé en base de données.
Alors attention, on ne chiffre pas le mot de passe, mais on le hache.
C'est deux notions qui sont complètement différentes entre l'encrépition et la


Une donnée chiffrée, elle doit pouvoir être déchiffrée grâce à la clé de chiffrement
utilisée et on doit pouvoir retrouver l'information originelle intacte.
Alors que de leur côté, les méthodes de HH sont dites destructives.
On ne peut pas retrouver l'information originelle intacte.
Si jamais vous n'êtes pas trop familier avec le concept de HH, je vous invite à écouter
le dernier épisode du podcast parce que l'épisode y est consacré.
Une fois qu'on a acheté le mot de passe, l'idéal, c'est d'utiliser ce qu'on appelle un grain de sel.
Parce qu'à première vue, quand vos mots de passe y sont achés avec un algorithme suffisamment
sécurisé, même si votre base de données est subie une fuite, les attaquants n'ont pas directement
accès au mot de passe en clair. Mais si jamais les attaquants arrivent à découvrir quel algorithme
de HH a été utilisé, ce qui est assez facile au final à faire, il leur reste quand même la
possibilité de générer des mots de passe et de les comparer aux HH trouvés en utilisant
des techniques comme le bruit de force. Le bruit de force est tester toutes les possibilités de
suite de caractères différents ou les dictionnaires. C'est tester des combinaisons de mots issus
d'informations personnelles, de mots usuels, etc. Donc en gros, l'idée, c'est qu'ils construisent
ce qu'on appelle des rainbow tables. C'est d'immenses tableaux de HH déjà généré.
Avec les méthodes que je vous ai dit au-dessus, avec l'algorithme de HH qui correspond à votre site.
Et donc ces tableaux peuvent peser parfois jusqu'à plusieurs terra octées, mais ça leur permet
tout simplement de comparer les HH trouvés dans la base de données avec les HH qui sont générés de
leur côté. Si ça correspond, il y a de fortes chances que le mot de passe qu'ils ont eux en
clair du coup pour générer la rainbow table correspond. Mais pour freiner, voire parfois,
empêcher ces attaques, on utilise la méthode du grain de sel aussi appelée du salage qui consiste
simplement à ajouter une chaîne de caractères au mot de passe avant qu'il soit haché. Ce grain de
sel, ça permet de rallonger la taille du mot de passe de base et donc de le rendre plus long, on va
dire à retrouver, parce que plus long à générer. Et surtout de limiter l'utilisation de dictionnaires
et de rainbow tables. Alors il y a deux méthodes différentes de grain de sel, enfin ou de salage.
Il y a le salage statique. Donc le salage statique ça consiste à ajouter toujours la même chaîne
de caractères pour tous les mots de passe enregistrés dans la base. Ce grain de sel, évidemment,
il doit rester secret parce que sinon son efficacité est complètement inutile. Et cette
technique a permis de ralentir la récupération des mots de passe, mais l'empêche pas l'utilisation
de rainbow table parce que, simplement, ces dernières devront être générées spécifiquement pour ce
site en particulier, mais ça n'empêche pas l'utilisation. Ensuite, il y a le salage dynamique.
Le salage dynamique, ça 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ées. Ou au mieux dans une base de données
séparée. Comme ça, si votre première base de données séparée tombe, et bien votre deuxième base
de données avec les grains de sel, elle n'est pas forcément impactée. Donc là, pour le coup,
c'est une technique qui vise à empêcher complètement l'utilisation d'une rainbow
table sur l'entierté de la base de données. Parce que chaque utilisateur, comme il a un grain de
sel différent dans son mot de passe, c'est impossible de précalculer tous les haches pour tous
les grains de sel possible. Voilà, donc là, je vous ai donné un petit peu une vue d'ensemble des
bonnes pratiques à faire. Ce qui a à retenir absolument, c'est le HTTPS, le hachage et le
grain de sel, même si c'est juste un grain de sel statique, au moins ça vous empêchera, on va dire,
je dirais 98% des problèmes. Donc voilà, c'est vraiment ce qu'il y a à retenir et j'espère qu'avec
ça, vous pourrez mettre en place des applications encore un peu plus sécurisées parce que ce qu'il
faut retenir, c'est évidemment jamais, jamais, jamais stocker un mot de passe en clair. J'espère
que cet épisode vous a été utile. Moi, je vous dis à la semaine prochaine pour un nouvel épisode
du podcast. Si jamais vous écoutez ça sur une plateforme qui vous permet de donner une note
au podcast, n'hésitez pas à nous mettre 5 étoiles, ça va permettre de faire gagner en visibilité le
podcast et donc de soutenir notre travail. Moi, je vous dis à la semaine prochaine, merci !