Décoder l'identifiant stocké : le base64 n'est pas du chiffrement

Les applications ont besoin d'un mot de passe pour se connecter à leur base de données, et ce mot de passe doit se trouver quelque part où l'application peut le lire au démarrage : un fichier de configuration, une variable d'environnement, ou une table de paramètres. Un schéma courant mais erroné consiste à encoder le mot de passe en base64 avant de le stocker et à appeler cela du « chiffrement » pour que ça paraisse plus sûr lors d'une revue. Ce n'est pas du chiffrement. Le base64 est un encodage réversible et public, sans clé, si bien que la valeur obscurcie n'est qu'à un décodage du mot de passe réel.

Vous pouvez reconnaître du base64 dans un bloc stocké de la même manière que partout ailleurs. Il utilise des lettres majuscules et minuscules ainsi que des chiffres, peut comporter un ou deux symboles, et se termine fréquemment par un ou deux signes = de remplissage. La valeur stockée ici se termine par ==, ce qui indique fortement que la forme externe est du base64. Le décoder révèle le mot de passe d'origine en clair, exactement tel que l'application l'utilise.

L'impact sur la sécurité est direct. Quiconque peut lire la valeur stockée, que ce soit via une configuration divulguée, une sauvegarde, une ligne de log, ou un hôte compromis, peut récupérer le mot de passe de la base de données en production en un seul clic, car aucun secret n'est nécessaire pour inverser le base64. C'est pourquoi le stockage en base64 est un cadeau pour l'élévation de privilèges : il transforme un accès en lecture à un fichier en des identifiants complets de base de données. Les boutons ROT13, hex, URL et inverse attendent des formats d'entrée différents et sont des leurres ici.

• Croire que « chiffré » signifie sûr. Appeler le base64 « chiffrement » ne lui donne pas de clé. La valeur est réversible par quiconque peut la lire.
• Choisir le mauvais décodeur. Le hex n'utilise que 0-9a-f et le ROT13 conserve la même longueur et la même forme. La casse mixte, les symboles et le remplissage == pointent vers le base64.
• Soumettre le bloc encodé. La réponse est le mot de passe décodé, pas la chaîne base64.
• Supposer que le stockage au repos est peu risqué. Une configuration ou une sauvegarde lisible transforme un mot de passe en base64 directement en accès à la base de données en production.

La correction consiste à cesser de traiter le base64 comme une protection et à gérer correctement les identifiants stockés. Un mot de passe de base de données que l'application doit utiliser à l'exécution devrait provenir d'un gestionnaire de secrets, pas d'un bloc base64 dans un fichier, et la valeur ne devrait jamais être qualifiée de chiffrée à moins qu'elle ne le soit réellement.

• Stockez les identifiants de service dans un gestionnaire de secrets dédié avec contrôle d'accès et journalisation d'audit, pas dans une configuration en clair.
• Si un identifiant doit se trouver dans un fichier de configuration, chiffrez-le avec un chiffrement authentifié utilisant une clé que l'application récupère depuis un stockage géré, jamais du base64.
• Restreignez l'accès en lecture aux fichiers de configuration, aux sauvegardes et aux logs afin que la valeur stockée ne soit pas exposée sans précaution.
• Faites tourner tout identifiant qui a déjà été stocké en base64, car il doit être considéré comme déjà divulgué.