In this article
9 bonnes pratiques pour stocker les mots de passe
Le stockage sécurisé des mots de passe est un défi pour toutes les organisations, des petites startups aux grandes entreprises.
Dans les startups récemment créées, le manque de ressources peut conduire à recruter au départ des développeurs débutants, qui ne maîtrisent pas suffisamment les bonnes pratiques de stockage des mots de passe. Comme l’authentification est souvent ajoutée assez tôt dans le processus de développement, cela peut entraîner de mauvaises pratiques de stockage des mots de passe.
Cela conduit à des implémentations médiocres qui constituent le socle de l’application. Et bien sûr, plus un module est central pour une application, moins le développeur sera enclin à le modifier plus tard au cours du projet, par crainte de provoquer une panne.
La mauvaise implémentation de l’authentification est donc conservée jusqu’à ce que la situation se dégrade et que quelqu’un parvienne à dérober les mots de passe de vos utilisateurs.
Les bonnes pratiques de sécurité des applications sont essentielles dès la phase de développement pour prévenir les intrusions. Mais rien n’est sécurisé à 100 % : vous devez donc prendre des mesures pour protéger les mots de passe de vos utilisateurs.
Dans cet article, nous abordons les bonnes pratiques les plus importantes pour stocker les mots de passe.
1. Protégez vos bases de données et vos conteneurs
La sécurité des bases de données ne concerne pas uniquement les bonnes pratiques liées aux mots de passe. Elle s’applique à toutes les données qui y sont stockées et ne doit donc pas être négligée.
Si un attaquant ne peut pas accéder à vos données, il ne pourra pas non plus les déchiffrer. Pensez donc à consulter également les bonnes pratiques de sécurité de votre fournisseur de bases de données.
Bien sûr, cela concerne tous vos systèmes, pas seulement vos bases de données. Si vous utilisez un moteur de conteneurs populaire comme Docker, vous êtes exposé à tous les problèmes qu’il entraîne. Ne négligez donc pas la sécurité des conteneurs et veillez à surveiller vos systèmes comme il se doit.
La sécurité des conteneurs, pensée pour les développeurs
Snyk détecte et corrige automatiquement les vulnérabilités dans les images de conteneurs et les workloads Kubernetes.
2. Hachez tous les mots de passe
Ne stockez jamais les mots de passe en clair. Créez toujours leur empreinte et stockez-la à la place. Pour le stockage des mots de passe, le hachage est préférable au chiffrement, car une empreinte ne peut pas être inversée.
Lorsqu’un utilisateur tente de se connecter, vous pouvez recréer l’empreinte à partir du mot de passe saisi et vérifier si elle correspond à celle enregistrée lors de son inscription. Personne ayant accès à la base de données ne pourra lire ni deviner le mot de passe d’origine à partir de cette empreinte, pas même vous ou vos collègues. Le hachage signifie également qu’il n’existe aucune clé de chiffrement susceptible d’être dérobée.
3. Utilisez une fonction de hachage robuste
Toutes les fonctions de hachage ne se valent pas. Certaines ne sont pas sûres d’un point de vue cryptographique, et d’autres sont conçues pour être rapides à calculer — ce qu’il faut éviter pour hacher un mot de passe.
Les fonctions de hachage rapides permettent aux attaquants de tester par force brute de nombreuses chaînes aléatoires jusqu’à retrouver les mots de passe dissimulés dans les empreintes. Vous devez leur compliquer la tâche. Même si vous devrez vous aussi utiliser ces fonctions lentes pour hacher un mot de passe lors de l’inscription ou de la connexion, vous n’aurez pas à les appliquer à des millions de chaînes aléatoires.
OWASP recommande d’utiliser Argon2 pour hacher les mots de passe. Si ce n’est pas possible, utilisez bcrypt ; et si bcrypt n’est pas disponible, utilisez scrypt.
4. Salez vos mots de passe
Saler un mot de passe consiste à lui ajouter une chaîne aléatoire avant de le hacher. Ainsi, les empreintes de mots de passe connus ne sont pas identiques. Un attaquant peut disposer d’une table répertoriant ces mots de passe et leurs empreintes correspondantes, et vérifier simplement lesquels vos utilisateurs ont employés. Cette table peut contenir l’empreinte du mot de passe password, mais pas celle de &()/&IJDNSBAEpassword.
Les utilisateurs ont aussi tendance à réutiliser le même mot de passe dans plusieurs applications. Si un attaquant accède aux mots de passe divulgués de plusieurs applications populaires, le salage avant le hachage l’empêchera de les comparer.
La chaîne de salage est stockée dans votre base de données avec le mot de passe. Les bibliothèques de hachage modernes, comme Argon2 ou bcrypt, salent automatiquement les mots de passe avant de les hacher.
5. Ajoutez un pepper à vos mots de passe
L’ajout d’un pepper fonctionne comme le salage : vous ajoutez une chaîne aléatoire avant le hachage.
La différence, c’est qu’avec le pepper, la chaîne est identique pour tous les mots de passe, mais qu’elle n’est pas stockée avec eux dans la base de données. Vous devez plutôt la stocker dans le système de fichiers ou dans un stockage d’objets. L’emplacement importe peu, tant qu’il est différent de celui de votre base de données de mots de passe.
Même si un pirate parvient à accéder à votre base de données, il lui manquera toujours une donnée, et il lui sera beaucoup plus difficile d’associer vos empreintes aux mots de passe correspondants.
6. Mettez à jour vos facteurs de travail
Même si les fonctions de hachage prennent un certain temps à effectuer leur travail, l’augmentation de la puissance de calcul accélère le processus. La création d’une empreinte qui prenait quelques secondes au moment où le code a été écrit peut ne prendre que quelques millisecondes à un attaquant équipé d’un ordinateur plus performant.
Pour résoudre ce problème, les fonctions de hachage utilisent un paramètre appelé « facteur de travail ». Celui-ci augmente le nombre d’itérations effectuées sur votre empreinte, et donc le temps nécessaire.
Deux éléments sont à prendre en compte pour le facteur de travail. D’un côté, vous ne voulez pas rendre le hachage trop facile pour un attaquant ; de l’autre, vous ne voulez pas compliquer excessivement la connexion. En règle générale, évitez donc de choisir des facteurs de travail très élevés.
Si vous mettez à niveau votre infrastructure et que vos serveurs deviennent plus performants, mettez également à jour vos facteurs de travail afin de tirer parti de ce gain de performance pour renforcer votre sécurité.
7. N’obligez pas les utilisateurs à réinitialiser leurs mots de passe
On considérait autrefois comme une bonne pratique d’obliger les utilisateurs à changer de mot de passe toutes les quelques semaines. L’idée était de donner une date d’expiration aux mots de passe dérobés. En pratique, cependant, cela ne faisait que frustrer les utilisateurs et les inciter à choisir des mots de passe plus simples et moins sûrs.
Si des exigences de conformité vous imposent encore cette pratique dépassée, vous ne pourrez pas y échapper. Mais si aucun facteur externe ne vous oblige à suivre ces recommandations, ne demandez pas à vos utilisateurs de changer leurs mots de passe. Vous obtiendrez ainsi de meilleurs mots de passe à long terme.
8. Vérifiez la longueur des mots de passe, pas leur complexité
Dans l’ensemble, la longueur d’un mot de passe compte davantage que sa complexité. Plus il est long, plus il faut de temps pour le pirater par programmation — parfois des années. C’est une bonne chose, car un utilisateur peut mieux retenir IonceateahamburgerinLondon que x5§.11#.
C’est pourquoi vous ne devriez pas exiger que les utilisateurs emploient des chiffres ou des caractères spéciaux. Laissez-les simplement choisir le mot de passe qu’ils souhaitent et veillez à ce qu’il comporte plus de cinq caractères.
9. Comparez les mots de passe aux dictionnaires et aux listes de blocage
Même si vous ne devriez pas imposer aux utilisateurs des mots de passe complexes arbitraires, il est recommandé de comparer les nouveaux mots de passe aux mots de passe connus figurant dans les dictionnaires publics et les listes de blocage. Si un nouveau mot de passe correspond à une entrée de ces sources, informez l’utilisateur et veillez à ce qu’il ne l’utilise pas.
Les pirates s’appuient également sur ces sources de mots de passe pour les comparer aux empreintes qu’ils dérobent. Vérifier les mots de passe à l’aide de ces listes compliquera donc encore davantage la découverte de vos mots de passe en clair.
Les bonnes pratiques de stockage des mots de passe sont essentielles au SDLC
Les mots de passe sont indispensables à votre application. Leur stockage correct est important sur le long terme. Selon le caractère sensible des données utilisateur, le stockage d’un mot de passe compromis peut mettre toute votre entreprise en péril.
De mauvaises pratiques en matière de mots de passe peuvent entraîner de nombreux problèmes de sécurité : elles peuvent faciliter les attaques externes comme internes, tout en vous exposant aux mots de passe réutilisés dans d’autres applications. Si les utilisateurs respectent moins les règles, leur frustration peut également s’accentuer, ce qui augmente les risques de sécurité. Pire encore, cela peut les dissuader d’utiliser votre service.
Lors du développement de logiciels critiques, les bonnes pratiques de sécurité doivent être appliquées à chaque étape du processus. La sécurité des mots de passe n’est qu’un aspect du SDLC sécurisé. Empêchez les attaquants d’accéder à vos mots de passe dès le départ. L’analyseur statique de sécurité des applications Snyk Code détecte les vulnérabilités connues dans votre code et vous indique comment les corriger.
Sécurisez vos dépendances open source
Les outils Snyk, conçus pour les développeurs, génèrent en un clic des pull requests correctives pour vos dépendances open source vulnérables et leurs dépendances transitives.