11 juillet 2023
Secrets humains et machines
Il est essentiel de différencier les secrets humains et les secrets machines.
Les secrets humains désignent des mots de passe utilisés par des humains. Les humains ont tendance à choisir des mots de passe courts, faciles à retenir et potentiellement prévisibles. Cela les rend vulnérables aux attaques par dictionnaire ou par force brute.
D'un autre côté, les secrets machines sont des clés utilisées par des serveurs. Ils sont générés de manière aléatoire, longs et complexes.
Il est donc important de comprendre que ces deux types de secrets ne doivent pas être traités de la même manière, car ils présentent des problématiques de sécurité différentes.
5 erreurs à ne pas commettre
Secrets trop faibles
Un problème avec les secrets choisis par des humains est qu’ils sont souvent trop faibles, car ils doivent être mémorisables. On ne peut pas raisonnablement demander aux gens de choisir des mots de passe longs et complexes, car ils ne seront pas capables de s’en rappeler.
Mais alors, quelles recommandations faire aux gens pour qu’ils en choisissent des plus sécurisés ? Entrons dans les détails de quelques concepts pour y voir plus clair.
Hash
Le hash d’un mot de passe est un “condensat cryptographique”, c’est-à-dire une empreinte obtenue à partir du mot de passe. Il est facile à calculer, mais il est mathématiquement impossible de calculer le mot de passe à partir du hash.
On stocke souvent les hash des mots de passe dans les bases de données, plutôt que ces derniers en clair. Cela est une bonne pratique, car si la base de données fuite, il est théoriquement impossible de récupérer les mots de passe à partir des hash.
Attaque en ligne et hors ligne
Il existe deux types d’attaque pour trouver un mot de passe : les attaques en ligne et les attaques hors ligne.
Lors d'une attaque en ligne, un attaquant se trouve sur une page de connexion et essaye des mots de passe 1 à 1. Dans ce cas, l’attaquant est limité dans ses essais, car si la page de connexion est bien sécurisée, il ne pourra pas essayer beaucoup de mots de passe avant d’être bloqué du système.
Dans une attaque hors ligne, l’attaquant a récupéré le hash d’un mot de passe, par exemple lors d’une fuite de base de données. Comme vu précédemment, il ne peut pas directement calculer le mot de passe à partir du hash. Par contre, il peut le retrouver par une méthode de brute force.
Un hash est déterministe : cela signifie que si on calcule celui d’un même mot de passe, on trouvera toujours le même résultat. Pour retrouver le mot de passe, un attaquant peut donc calculer sur sa machine (hors-ligne) le hash de tous les mots de passe possibles, jusqu’à tomber sur un hash égal à celui qu’il a récupéré. Il sait alors qu’il a trouvé le mot de passe.
Dans cette attaque, il n’a aucune restriction sur son nombre d’essais, si ce n’est les capacités de sa machine. Cette attaque est donc plus dangereuse !
Par exemple, sur l’image ci-dessus, un attaquant a obtenu un hash et veut retrouver le mot de passe associé. Il calcule le hash de toutes les combinaisons de lettres, chiffres et caractères spéciaux de 8 caractères. Il finit par trouver un hash égal à celui qu’il a récupéré. Il sait alors que le mot de passe est “M2y3!q?3” !
Mot de passe fort
Dans le cas d’une attaque hors-ligne, plus le mot de passe est court, plus il peut être découvert rapidement. Par exemple, pour les hash des mots de passe Windows, il est possible de calculer le hash de tous les mots de passe de 8 caractères en seulement 24 heures. Mais si on monte à 12 caractères, cela prendrait environ 1 an ! Il est donc important qu’un mot de passe soit long pour être sécurisé.
Évidemment, un mot de passe simplement long n’est pas suffisant. Vous comprendrez facilement que “secretsecret” n’est pas un bon mot de passe, même s’il fait 12 caractères ! Un attaquant pourrait le trouver en utilisant une attaque par dictionnaire, c’est-à-dire en utilisant une liste de mots courants ou prévisibles.
Il faut donc choisir un mot de passe long, mais qui ne soit pas trop prévisible. Pour cela, pas besoin de choisir quelque chose de très complexe avec beaucoup de chiffres et de caractères spéciaux aléatoires. Cela rendrait le mot de passe difficile à retenir. Il faut juste ajouter un peu de complexité, pour que ça reste mémorisable, sans être facile à deviner.
Solutions :
- Utiliser une politique de mots de passe pour que vos utilisateurs aient des mots de passe longs, d’un minimum de 12 caractères. Il faut aussi ajouter un peu de complexité, en demandant l’utilisation d’une majuscule, d’un chiffre, et d’un caractère spécial. Le top serait d’interdire l’utilisation de certains mots de passe trop basiques, comme “Password1!”, en utilisant une blacklist.
- Encore mieux : forcer l’utilisation d’un gestionnaire de mots de passe. Plus besoin de choisir entre longueur et complexité, car il générera automatiquement des mots de passe à la fois longs et complexes, et s’occupera de s’en rappeler pour vos utilisateurs ! Vous pouvez par exemple utiliser Dashlane, qui à l’avantage de permettre le partage de secrets entre utilisateurs.
Réutilisation de ses secrets
La réutilisation de secrets est un autre problème que l’on rencontre souvent sur des projets. Cela se produit lorsque le même secret est utilisé pour l'authentification sur différents environnements ou applications, ou par plusieurs utilisateurs.
Si un secret fuit, il met en péril tous les environnements ou applications qui l’utilisent. Cela signifie qu'un seul incident de sécurité peut compromettre l'ensemble du système.
De plus, si votre secret fuite et que des mesures correctives doivent être prises, vous allez devoir trouver tous les usages de celui-ci pour l’invalider. C’est extrêmement chronophage !
Pour vous donner un exemple concret, il nous a fallu trois mois pour invalider seulement deux secrets sur un projet. Ils étaient très difficiles à trouver, car il était utilisé sur des applications et des environnements différents. Ils étaient aussi stockés à différents endroits : dans des gestionnaires de mots de passe, dans Vault, ou encore dans les secrets GitHub.
Et pour compliquer tout ça, ils étaient stockés dans différents formats : parfois en clair, parfois en base64. Ça rend le fait de les trouver pour les invalider très compliqué !
Solutions :
- Générer un secret différent pour chaque usage spécifique.
- Encore une fois, utiliser un gestionnaire de mots de passe. Il permet de générer automatiquement et de stocker des secrets uniques pour chaque utilisation.
Secrets en clair dans le code
Une autre erreur que nous avons souvent rencontrée sur des projets est de trouver des secrets en clair dans le code. Cela les rend vulnérables à des risques de fuite ou de compromission.
Attention : Si vous remarquez qu’un secret a été publié dans le code d’un de vos repositories, il ne suffit pas de l’effacer du code pour résoudre ce problème. Le secret a déjà fuité, donc le risque existe déjà. Et même si vous l’effacez du code, il sera toujours présent dans l’historique de votre repository ! Pensez donc bien à l’invalider.
Solutions :
- Utiliser des outils spécifiques pour détecter si un développeur tente de publier un secret en clair dans le code. Gitleaks, TruffleHog ou GitGuardian peuvent être utilisés pour alerter les développeurs lorsqu’ils essayent de publier des secrets. Cette solution permet de sensibiliser les développeurs pour les inciter à changer leurs pratiques.
- Au lieu d’utiliser vos secrets en clair dans le code, injecter les secrets au moment de l'exécution du code en tant que variables d'environnement. Pour ceci, vous pouvez utiliser des outils comme Vault ou ArgoCD.
Secrets trop privilégiés
On trouve souvent des secrets machines avec des permissions trop privilégiées. On peut s’imaginer que cela est moins important qu’avec un secret humain, car ceux-ci sont utilisés par des serveurs. Mais ils peuvent tout autant être compromis que les secrets humains, par exemple s’ils sont écrits en clair dans le code.
Solutions :
- Adopter le principe du moindre privilège. Cela signifie qu'il faut accorder aux secrets machine uniquement les privilèges nécessaires pour effectuer leurs tâches spécifiques, sans leur octroyer des permissions excessives qui pourraient être exploitées en cas de compromission. Nous vous conseillons de faire une passe sur vos secrets et de déterminer quelles permissions leur sont effectivement nécessaires pour effectuer leurs tâches.
Secrets long terme
Cette dernière erreur tend à s’améliorer, mais il est encore courant de trouver des secrets qui restent valides sur de longues périodes. Il est important que les secrets aient une période de validité courte.
L’idée traditionnelle pour remédier à ce problème avec les secrets humains consiste à encourager la rotation régulière des mots de passe, en demandant aux individus de les changer fréquemment.
Attention : cette pratique peut être contreproductive ! Au lieu d'avoir un mot de passe fort et unique, il a été observé que les gens tendent à utiliser des schémas prédictibles lorsqu'ils sont contraints de changer régulièrement leurs mots de passe.
Par exemple, il est très courant d’observer ce genre de mots de passe dans les entreprises obligeant un changement de mots de passe tous les 3 mois : "Janvier2023!", "Avril2023!", etc. Cela réduit considérablement l'efficacité de la rotation des mots de passe.
Solutions :
- Utiliser des outils de rotation de mots de passe, tels que Vault, pour les secrets humains et machine. Ces outils sont capables de générer des secrets à court terme et de les mettre à jour automatiquement à intervalles réguliers. Cela garantit que les secrets soient changés régulièrement, tout en évitant la réutilisation de schémas prédictibles.
- Utiliser des rôles IAM cloud qui permettent d'attribuer des privilèges temporaires et spécifiques aux applications, réduisant ainsi la durée de validité des secrets.
Conclusion
La gestion efficace des secrets est essentielle pour renforcer la sécurité de votre infrastructure. En évitant les erreurs courantes expliquées dans cet article, vous pouvez réduire considérablement les risques de compromission et ainsi améliorer la sécurité globale de votre infrastructure.