Je ne vais évidemment pas ici expliquer qu'un mot de passe ne doit pas être stocké en clair, ce n'est pas le propos. Mais en tant que développeurs, nous faisons face à un besoin de mise à jour constante et il m'arrive encore de travailler ou reprendre des projets où les mots de passe sont stockés en clair !
Une fois cette sombre histoire du développement web passé, il fut un temps où stocker l'empreinte d'une fonction de hashage d'un mot de passe avec MD5 ou SHA-1 fut très apprécié reconnaissons-le.
C'était simple, efficace et cela permettait d'empêcher à un attaquant de connaître le mot de passe en clair à partir du hash.
Un peu plus tard il fut recommandé d'utiliser le nouveau standard SHA-2 et d'y ajouter un salage pour éviter les attaques par table arc-en-ciel (rainbow tables).
Le principe de base d'une fonction de hashage est d'être conçue pour être rapide afin de déterminer l'empreinte de très gros fichiers rapidement.
C'est hélas là que le bât blesse puisque c'est également ce qui les rend plus vulnérables aux attaques par dictionnaire ou par force brute basée principalement sur la puissance de calcul.
Plus une fonction de hashage sera performante, plus il sera rapide à une personne malveillante de retrouver des mots passes.
Même si l'utilisateur a un mot de passe complexe et sécurisé, notre rôle en tant que développeur d'applications est de sécuriser son stockage. Prenons un exemple simple avec nos amis Alice et Bob, Alice sera la méchante pirate pour une fois :
"Bob protège son site web avec un mot de passe de 9 caractères comprenant des lettres majuscules, des lettres minuscules et des chiffres (oui il n'utilise hélas pas de caractère spécial)"
"Alice trouve un moyen de se procurer l'empreinte du mot de passe de Bob et décide de l'attaquer par force brute."
Il existe 629 - 628 solutions pour le mot de passe de Bob."
Voici un benchmark qui a quelques années maintenant de la société Sagitta HPC (arrondis) :
| Fonction | Temps maximum |
|---|---|
| MD5 | 24 heures |
| SHA-1 | 75 heures |
| SHA-256 | 7 jours |
| scrypt | 354 années |
| Bcrypt | 3173 années |
Et la puissance de calcul ne fait qu'évoluer, plus le temps passe et plus ces temps sont raccourcis. Nous devons donc migrer nos algorithmes et donc nos mots de passe régulièrement.
Nous sommes passés il y a quelques années à BCrypt, avec l'augmentation de la puissance de calcul, nous mettons à jour régulièrement le nombre de "cost" de celui-ci, et au jour où j'écris ces lignes, nous allons passer à un nouvel algorithme : Argon2.
Dans un prochain article, je décrirais comment procéder dans une application sous Symfony mais la mise en œuvre sera similaire avec d'autres architectures et frameworks.
3