Accueil / Articles / Mots de passe de bases de données : bonnes pratiques par moteur

› Article

Mots de passe de bases de données : les bonnes pratiques, moteur par moteur.

Un bon mot de passe ne suffit pas : encore faut-il le poser correctement selon le moteur, sans casser une chaîne de connexion, et le renouveler sans interruption. Voici les règles communes et les particularités de chaque moteur.


Les règles communes

  • Aléatoire et long : 16 à 24 caractères pour un compte applicatif, qui n'est jamais saisi à la main.
  • Unique par compte et par environnement (production, test, développement).
  • Stocké dans un coffre (gestionnaire de mots de passe, Azure Key Vault, AWS Secrets Manager, Google Secret Manager), jamais dans un dépôt de code.
  • Renouvelé selon un calendrier et après tout départ ou incident, avec une procédure qui évite l'interruption de service.

Pour les générer, l'outil gratuit et sans publicité motdepasse.dev, que nous avons créé, produit des mots de passe complexes, avec choix de la longueur, des types de caractères et exclusion des caractères ambigus. D'après le site, la génération est locale, sans envoi de données.

Oracle

  • Un mot de passe contenant des caractères spéciaux se place entre guillemets doubles : ALTER USER app IDENTIFIED BY "M0t#de!passe".
  • Les mots de passe distinguent les majuscules et les minuscules à partir d'Oracle 11g.
  • Les profils (PASSWORD_LIFE_TIME, FAILED_LOGIN_ATTEMPTS, fonction de vérification) imposent la politique. Pour un compte applicatif, adaptez la durée de vie pour éviter une expiration en pleine production.

PostgreSQL

  • Dans psql, la commande \password nom_du_role évite que le mot de passe apparaisse en clair dans l'historique ou les journaux.
  • Le chiffrement du mot de passe stocké doit être scram-sha-256, valeur par défaut des versions récentes. L'ancien md5 est à abandonner.
  • Dans une URL de connexion (postgresql://utilisateur:motdepasse@hote/base), les symboles spéciaux doivent être encodés (par exemple @ devient %40), sinon la connexion échoue.

MySQL et MariaDB

  • ALTER USER 'app'@'%' IDENTIFIED BY '...' : l'apostrophe et la barre oblique inverse dans le mot de passe doivent être échappées. Évitez-les pour les comptes techniques.
  • Le composant ou plugin de validation des mots de passe permet d'imposer longueur et complexité.
  • Un compte est défini par son nom et son hôte : changer le mot de passe de 'app'@'%' ne touche pas 'app'@'localhost'.

CosmosDB et bases managées dans le cloud

Les services managés utilisent souvent des clés d'accès plutôt que des mots de passe. Azure Cosmos DB propose deux clés, principale et secondaire : on fait basculer les applications sur la secondaire, puis on régénère la principale, sans interruption.

Quand le service le permet, l'authentification par identité (Microsoft Entra ID, rôles IAM) supprime le secret à stocker.

Le piège commun : les chaînes de connexion

Quel que soit le moteur, un symbole spécial dans le mot de passe peut casser une URL ou une chaîne de connexion. Pour un compte applicatif, mieux vaut un mot de passe long (24 caractères et plus) avec lettres et chiffres et peu de symboles, qu'un mot de passe court bourré de ponctuation.

Outil gratuit, sans publicité : motdepasse.dev

Générez un mot de passe aléatoire et complexe : longueur, jeux de caractères et exclusion des caractères ambigus au choix, génération locale dans le navigateur.

Ouvrir motdepasse.dev →

À retenir

  • Aléatoire, long, unique par compte et par environnement, rangé dans un coffre.
  • Oracle : guillemets doubles. PostgreSQL : encodage dans les URL et scram-sha-256. MySQL et MariaDB : échappement et hôte du compte.
  • Sur les services managés, les clés tournent en alternance ; l'authentification par identité est préférable.
  • Préférez un mot de passe long avec peu de symboles aux chaînes courtes très ponctuées.

Un besoin à cadrer ?

Un premier échange suffit à définir le périmètre, le moteur concerné et la suite.

Demander un devis