Skip to content

Gestion des mots de passe d’application dans une BD

Distinction des Types d’Utilisateurs

Utilisateurs de l’Application Web - Stockés dans, par exemple, la table users de la base de données - S’authentifient via l’interface web - Leurs identifiants et mots de passe sont gérés par l’application - Leurs permissions sont gérées au niveau de l’application

Utilisateurs de la Base de Données - Créés directement dans PostgreSQL - Utilisés pour la connexion à la base de données - Gérés par l’administrateur de la base de données - Leurs permissions sont gérées via les commandes GRANT/REVOKE

Bonnes Pratiques

Configuration de l’Application - Créer un seul utilisateur PostgreSQL dédié pour l’application (ex: web_app)[1] - Cet utilisateur unique sert d’intermédiaire entre l’application et la base de données - Ne pas créer un utilisateur PostgreSQL pour chaque utilisateur de l’application[1]

Exemple de Configuration

-- Création de l'utilisateur pour l'application
CREATE ROLE web_app WITH LOGIN PASSWORD 'mot_de_passe_securise';

-- Attribution des permissions nécessaires
GRANT SELECT, INSERT, UPDATE, DELETE ON users TO web_app;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO web_app;

Sécurité - L’application doit agir comme gardien d’accès aux données[1] - Limiter les privilèges de l’utilisateur PostgreSQL aux opérations strictement nécessaires[4] - Ne jamais donner les droits superutilisateur à l’utilisateur de l’application[4] - Implémenter un système de contrôle d’accès basé sur les rôles (RBAC) au niveau de l’application[4]

Authentification des Utilisateurs Web - Gérer l’authentification des utilisateurs web via la table users - Utiliser des sessions ou des tokens pour maintenir l’état de connexion - Implémenter une politique de mots de passe forts - Stocker uniquement les hachages des mots de passe, jamais en clair

Cette approche permet une séparation claire des responsabilités tout en maintenant un niveau de sécurité élevé pour l’application et la base de données.

Citations: [1] https://stackoverflow.com/questions/17475805/application-user-database-user [2] https://www.strongdm.com/blog/postgres-create-user [3] https://www.linkedin.com/pulse/17-users-vs-roles-postgres-rajneesh-verma [4] https://www.percona.com/blog/postgresql-database-security-best-practices/

Exemple

Voici la table users pour gérer les mots de passe de manière sécurisée :

create table users
(
    id            int generated by default as identity primary key,
    username      varchar(16) unique not null,
    email         text unique not null,
    password_hash varchar(60) not null check (length(password_hash) = 60)
);

Explications des Modifications

La nouvelle colonne password_hash est conçue pour stocker des hachages bcrypt :

  • Le type varchar(60) est utilisé car bcrypt produit toujours une chaîne de 60 caractères
  • La contrainte check vérifie que le hachage a la bonne longueur
  • Le not null assure qu’un mot de passe est toujours requis

Bonnes Pratiques de Sécurité

  1. Ne jamais stocker les mots de passe en clair
  • Toujours utiliser une fonction de hachage cryptographique
  • bcrypt est recommandé, car il inclut automatiquement un “salt” et est résistant aux attaques par force brute
  1. Dans l’application

    # Exemple avec Python et bcrypt
    import bcrypt
    
    def hash_password(password):
        # Génère un salt et hache le mot de passe
        return bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt())
    
    def verify_password(password, hashed):
        # Vérifie si le mot de passe correspond au hash
        return bcrypt.checkpw(password.encode('utf-8'), hashed)
    

  2. Insertion d’un utilisateur

    -- Le hash du mot de passe doit être généré par l'application
    INSERT INTO users (username, email, password_hash)
    VALUES ('alice', 'alice@example.com', '$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewdsBXOX.eQrdKf.');
    

Considérations Additionnelles

  • Implémenter une politique de mots de passe forts (longueur minimale, complexité)
  • Ajouter éventuellement une colonne pour le sel si vous n’utilisez pas bcrypt
  • Considérer l’ajout de colonnes pour la gestion des tentatives de connexion échouées
  • Prévoir un mécanisme de réinitialisation de mot de passe

Utilisation de l’IA

Page rédigée en partie avec l’aide d’un assistant IA. L’IA a été utilisée pour générer des explications, des exemples et/ou des suggestions de structure. Toutes les informations ont été vérifiées, éditées et complétées par l’auteur.