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.
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.
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.
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” !
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 :
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 :
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 :
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 :
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 :
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.