🔝 Retour au Sommaire

16.2.1. Méthodes d'Authentification PostgreSQL

Introduction

L'authentification est le processus par lequel PostgreSQL vérifie l'identité d'un utilisateur qui tente de se connecter à la base de données. C'est une étape cruciale de la sécurité qui précède l'autorisation (ce que l'utilisateur peut faire une fois connecté).

PostgreSQL offre plusieurs méthodes d'authentification, chacune adaptée à des contextes et des niveaux de sécurité différents. Ces méthodes sont configurées dans le fichier pg_hba.conf (Host-Based Authentication).

Note pour débutants : Le fichier pg_hba.conf est le "gardien" de votre base de données. Chaque ligne définit une règle qui dit : "Pour tel type de connexion, depuis telle origine, vers telle base, par tel utilisateur, utilise telle méthode d'authentification."

Vue d'ensemble des méthodes

Méthode	Sécurité	Complexité	Usage typique
trust	⚠️ Aucune	Très simple	Développement local uniquement
password	⚠️ Faible	Simple	Obsolète - Ne pas utiliser
md5	⚠️ Moyenne	Simple	Déprécié depuis PG 14
scram-sha-256	✅ Forte	Simple	Standard recommandé
cert	✅ Très forte	Complexe	Environnements haute sécurité
ldap	✅ Forte	Complexe	Intégration entreprise (Active Directory)

1. La méthode `trust` : Confiance Aveugle

Concept

La méthode trust est la plus permissive : elle n'effectue aucune vérification. Si la connexion correspond aux critères (adresse IP, base de données, utilisateur), PostgreSQL accorde l'accès immédiatement, sans demander de mot de passe.

Fonctionnement

# Exemple dans pg_hba.conf
# TYPE  DATABASE    USER        ADDRESS         METHOD
local   all         all                         trust  
host    all         all         127.0.0.1/32    trust

Avec cette configuration :

L'utilisateur se connecte depuis localhost
PostgreSQL vérifie que la connexion vient bien de localhost
Aucun mot de passe n'est demandé
Connexion accordée immédiatement

Quand l'utiliser ?

✅ Cas d'usage légitimes :

Développement local sur votre machine personnelle
Tests rapides en environnement isolé (Docker, VM sans réseau)
Scripts administratifs locaux sur un serveur sécurisé

❌ Ne JAMAIS utiliser :

En production
Sur un réseau accessible depuis Internet
Sur des serveurs partagés
Pour des bases contenant des données sensibles

Exemple pratique

# Connexion sans mot de passe avec trust
psql -U postgres -d mydb
# ✅ Connexion immédiate, aucun mot de passe demandé

Risques

Sécurité nulle : Toute personne ayant accès au système peut se connecter
Usurpation d'identité facile : Un attaquant peut se faire passer pour n'importe quel utilisateur
Audit impossible : Difficile de tracer qui fait quoi réellement

💡 Astuce de sécurité : Si vous utilisez trust, limitez-la à local (connexions Unix socket) sur des systèmes où seuls des utilisateurs de confiance ont accès.

2. La méthode `password` : Mot de Passe en Clair

Concept

La méthode password demande un mot de passe, mais le transmet en clair (non chiffré) sur le réseau entre le client et le serveur.

Fonctionnement

# Exemple dans pg_hba.conf
host    all         all         192.168.1.0/24    password

Le client se connecte
PostgreSQL demande le mot de passe
Le client envoie le mot de passe en texte clair sur le réseau
PostgreSQL compare avec le hash stocké
Connexion accordée ou refusée

Pourquoi est-elle obsolète ?

🚨 Problème majeur : Sniffing réseau

Imaginez que le mot de passe est une lettre envoyée par la poste dans une enveloppe transparente. N'importe qui interceptant la lettre (le trafic réseau) peut lire le mot de passe.

# Ce qui transite sur le réseau :
Username: alice  
Password: SuperSecret123  ← 👁️ Visible en clair !

Statut actuel

Obsolète depuis plusieurs années
Remplacée par md5 (elle-même dépréciée) puis scram-sha-256
Maintenue uniquement pour compatibilité avec d'anciens systèmes

❌ Ne l'utilisez jamais

Il n'existe aucun cas d'usage légitime pour password dans un système moderne. Utilisez au minimum scram-sha-256.

3. La méthode `md5` : Le Hachage (Déprécié)

Concept

La méthode md5 représente une amélioration par rapport à password : le mot de passe est haché avant d'être transmis sur le réseau, rendant l'interception moins dangereuse.

Fonctionnement

# Exemple dans pg_hba.conf
host    all         all         192.168.1.0/24    md5

Processus :

Le serveur envoie un "salt" (grain de sel aléatoire) au client
Le client calcule : MD5(MD5(password + username) + salt)
Le client envoie ce hash au serveur
Le serveur effectue le même calcul et compare
Si les hashs correspondent, connexion accordée

Analogie pour débutants

Imaginez que votre mot de passe est transformé en un puzzle unique. Au lieu d'envoyer le mot de passe, vous envoyez l'image du puzzle. Même si quelqu'un intercepte l'image, il ne peut pas facilement retrouver le mot de passe original.

Pourquoi est-elle dépréciée ?

Faiblesses de MD5 :

Algorithme obsolète : MD5 est cassé cryptographiquement depuis les années 2000
Vulnérable aux attaques par dictionnaire : Avec des bases de hashs précalculés (rainbow tables)
Pas de résistance aux attaques par force brute : Trop rapide à calculer (des milliards de hashs/seconde)
Challenge-response faible : Un attaquant capturant le trafic peut tenter des attaques offline

Exemple d'attaque

# Un attaquant capture le trafic réseau
Hash capturé: 5f4dcc3b5aa765d61d8327deb882cf99

# Il utilise une rainbow table
5f4dcc3b5aa765d61d8327deb882cf99 = "password"
# ✅ Mot de passe découvert !

Statut actuel (PostgreSQL 18)

Déprécié depuis PostgreSQL 14 (2021)
Toujours supporté pour compatibilité ascendante
Migration fortement recommandée vers scram-sha-256
Peut générer des avertissements dans les logs

Migration de md5 vers scram-sha-256

-- Vérifier les utilisateurs en md5
SELECT rolname  
FROM pg_authid  
WHERE rolpassword LIKE 'md5%';  

-- Forcer la réinitialisation des mots de passe
ALTER USER alice PASSWORD 'NewSecurePassword123!';
-- Le nouveau hash sera en SCRAM si configuré

4. La méthode `scram-sha-256` : Le Standard Moderne ✅

Concept

scram-sha-256 (Salted Challenge Response Authentication Mechanism) est la méthode d'authentification par mot de passe recommandée depuis PostgreSQL 10 et par défaut depuis PostgreSQL 14.

C'est l'équivalent moderne et sécurisé de md5, utilisant des algorithmes cryptographiques robustes.

Fonctionnement

# Exemple dans pg_hba.conf
host    all         all         0.0.0.0/0         scram-sha-256

Processus (simplifié) :

Handshake initial : Le client annonce qu'il supporte SCRAM
Challenge du serveur : Le serveur envoie un nonce (nombre aléatoire) et un salt
Réponse du client : Le client calcule une preuve cryptographique basée sur :
- Son mot de passe
- Le salt du serveur
- Le nonce
- Un nombre élevé d'itérations (4096 par défaut)
Vérification mutuelle : Le serveur vérifie la preuve ET envoie sa propre preuve
Connexion sécurisée établie

Pourquoi est-elle supérieure ?

1. Résistance aux attaques par force brute

Temps pour tester 1 milliard de mots de passe :
- MD5     : ~2 secondes   ⚠️
- SCRAM   : ~8 heures     ✅ (grâce aux 4096 itérations)

2. Protection contre le rejeu (replay attacks)

Chaque session utilise un nonce unique. Un attaquant capturant le trafic ne peut pas le réutiliser.

3. Authentification mutuelle

Le client vérifie aussi l'identité du serveur, protégeant contre les serveurs malveillants.

4. Salt unique par utilisateur

Rend les attaques par rainbow tables inefficaces.

5. Compatibilité avec les normes

Basé sur RFC 5802 et RFC 7677, standards de l'industrie.

Configuration

Dans postgresql.conf :

# Définir SCRAM comme méthode par défaut pour les nouveaux mots de passe
password_encryption = 'scram-sha-256'  # Défaut depuis PG 14

Dans pg_hba.conf :

# Connexions locales
local   all             all                                     scram-sha-256

# Connexions réseau (avec SSL recommandé)
hostssl all             all             0.0.0.0/0               scram-sha-256

Création d'utilisateur avec SCRAM

-- La méthode moderne (PostgreSQL 14+)
CREATE USER alice WITH PASSWORD 'SecurePass123!';
-- Hash SCRAM automatiquement généré

-- Vérification du type de hash
SELECT rolname,
       CASE
           WHEN rolpassword LIKE 'SCRAM-SHA-256%' THEN 'SCRAM-SHA-256'
           WHEN rolpassword LIKE 'md5%' THEN 'md5'
           ELSE 'Aucun'
       END AS password_type
FROM pg_authid  
WHERE rolname = 'alice';  

-- Résultat attendu :
--  rolname |  password_type
-- ---------+-----------------
--  alice   | SCRAM-SHA-256

Migration complète vers SCRAM

Étape 1 : Configurer le serveur

# postgresql.conf
password_encryption = 'scram-sha-256'

Étape 2 : Mettre à jour pg_hba.conf

# Avant
host    all    all    0.0.0.0/0    md5

# Après
host    all    all    0.0.0.0/0    scram-sha-256

Étape 3 : Réinitialiser les mots de passe

-- Option 1 : Réinitialisation manuelle
ALTER USER alice PASSWORD 'NewSecurePassword';

-- Option 2 : Forcer les utilisateurs à changer leur mot de passe
-- (Implique de communiquer avec les utilisateurs)

Étape 4 : Redémarrer PostgreSQL

pg_ctl reload -D /var/lib/postgresql/data
# ou
systemctl reload postgresql

Compatibilité clients

La plupart des drivers modernes supportent SCRAM :

✅ psql (PostgreSQL 10+)
✅ psycopg3/psycopg2 (Python, version 2.8+)
✅ node-postgres (Node.js)
✅ pgx (Go)
✅ Npgsql (.NET)
✅ JDBC (Java)

⚠️ Attention : Les très vieux clients (<2017) peuvent ne pas supporter SCRAM.

Bonnes pratiques

Toujours utiliser avec SSL/TLS :

hostssl all all 0.0.0.0/0 scram-sha-256

Politique de mots de passe robuste :

-- Extension pour validation de mots de passe
CREATE EXTENSION IF NOT EXISTS passwordcheck;

Surveiller les tentatives échouées :

# postgresql.conf
log_connections = on
log_disconnections = on

Rotation régulière des mots de passe :
- Tous les 90 jours minimum pour les comptes critiques
- Utiliser des gestionnaires de mots de passe

5. La méthode `cert` : Authentification par Certificat

Concept

La méthode cert utilise des certificats X.509 (comme ceux de HTTPS) pour authentifier les utilisateurs. C'est l'une des méthodes les plus sécurisées, mais aussi les plus complexes à mettre en place.

Principe de fonctionnement

Analogie : Imaginez que votre mot de passe est remplacé par une carte d'identité électronique cryptographique. Le serveur vérifie que :

La carte est authentique (signée par une autorité de confiance)
La carte n'a pas expiré
La carte n'a pas été révoquée
La carte appartient bien à l'utilisateur qui se connecte

Architecture

┌─────────────┐                     ┌─────────────────┐
│   Client    │                     │  PostgreSQL     │
│             │                     │   Serveur       │
│ - Cert.crt  │◄────SSL/TLS────────►│  - CA.crt       │
│ - Key.key   │   (Chiffré)         │  - server.crt   │
└─────────────┘                     │  - server.key   │
                                    └─────────────────┘

Configuration

1. Prérequis : Génération des certificats

# Sur le serveur (simplifié - production nécessite une PKI)

# 1. Créer une Autorité de Certification (CA)
openssl req -new -x509 -days 3650 -nodes -text \
    -out ca.crt -keyout ca.key \
    -subj "/CN=PostgreSQL-CA"

# 2. Créer le certificat serveur
openssl req -new -nodes -text \
    -out server.csr -keyout server.key \
    -subj "/CN=pg.example.com"

openssl x509 -req -in server.csr -days 365 \
    -CA ca.crt -CAkey ca.key -CAcreateserial \
    -out server.crt

# 3. Créer un certificat client pour l'utilisateur 'alice'
openssl req -new -nodes -text \
    -out alice.csr -keyout alice.key \
    -subj "/CN=alice"

openssl x509 -req -in alice.csr -days 365 \
    -CA ca.crt -CAkey ca.key -CAcreateserial \
    -out alice.crt

2. Configuration PostgreSQL (postgresql.conf)

# Activer SSL
ssl = on  
ssl_cert_file = 'server.crt'  
ssl_key_file = 'server.key'  
ssl_ca_file = 'ca.crt'  # Pour vérifier les certificats clients  

# Optionnel : Niveau de sécurité TLS
ssl_min_protocol_version = 'TLSv1.3'  # PostgreSQL 18

3. Configuration pg_hba.conf

# TYPE  DATABASE    USER    ADDRESS           METHOD                  OPTIONS
hostssl all         alice   192.168.1.0/24    cert                    clientcert=verify-full  
hostssl all         bob     0.0.0.0/0         cert                    clientcert=verify-full

Options importantes :

clientcert=verify-full : Vérifie le certificat ET que le CN correspond à l'utilisateur PostgreSQL
clientcert=verify-ca : Vérifie seulement que le certificat est signé par la CA

Connexion côté client

# Placer les fichiers clients dans ~/.postgresql/
mkdir -p ~/.postgresql  
cp alice.crt ~/.postgresql/postgresql.crt  
cp alice.key ~/.postgresql/postgresql.key  
cp ca.crt ~/.postgresql/root.crt  
chmod 600 ~/.postgresql/postgresql.key  

# Connexion (aucun mot de passe demandé)
psql "host=pg.example.com user=alice dbname=mydb sslmode=verify-full"
# ✅ Authentification automatique via certificat

Avantages

Sécurité maximale :
- Pas de mot de passe à gérer ou à compromettre
- Impossible de deviner ou craquer (pas de force brute)
Authentification mutuelle :
- Le client vérifie le serveur
- Le serveur vérifie le client
Audit et non-répudiation :
- Chaque certificat est unique et traçable
- Révocation centralisée via CRL (Certificate Revocation List)
Intégration avec PKI d'entreprise :
- Utilisation de certificats existants
- Gestion centralisée

Inconvénients et défis

Complexité de mise en place :
- Infrastructure PKI nécessaire
- Gestion du cycle de vie des certificats (expiration, renouvellement)
- Courbe d'apprentissage
Gestion opérationnelle :
- Déploiement des certificats clients
- Révocation en cas de compromission
- Monitoring des expirations
Mobilité réduite :
- Les certificats doivent être présents sur le client
- Moins pratique pour connexions ad-hoc

Cas d'usage typiques

✅ Idéal pour :

Applications serveur-à-serveur (microservices)
Environnements haute sécurité (finance, santé, défense)
Connexions automatisées (scripts, CI/CD)
Conformité réglementaire (PCI-DSS, HIPAA)

❌ Moins adapté pour :

Utilisateurs finaux humains (lourdeur)
Environnements de développement rapides
Petites équipes sans compétence PKI

Combinaison avec SCRAM

Il est possible de combiner les deux :

# pg_hba.conf
hostssl all  admin   0.0.0.0/0  cert                    clientcert=verify-full  
hostssl all  users   0.0.0.0/0  scram-sha-256

Cela permet :

Certificats pour les connexions critiques (admin, applications)
SCRAM pour les utilisateurs standards

6. La méthode `ldap` : Intégration Entreprise

Concept

La méthode ldap permet à PostgreSQL de déléguer l'authentification à un annuaire LDAP externe, typiquement Active Directory (Microsoft) ou OpenLDAP.

Avantage principal : Centralisation. Les utilisateurs utilisent le même mot de passe pour PostgreSQL, Windows, Email, VPN, etc.

Fonctionnement

┌─────────────┐                ┌─────────────────┐               ┌────────────┐
│   Client    │───1. Login────►│   PostgreSQL    │──2. Verify──► │   LDAP     │
│  (alice)    │                │                 │   (alice)     │  Server    │
│             │◄──4. OK/Fail───│                 │◄─3. OK/Fail── │   (AD)     │
└─────────────┘                └─────────────────┘               └────────────┘

Étapes :

L'utilisateur Alice se connecte avec son login/password
PostgreSQL intercepte la tentative
PostgreSQL envoie les credentials au serveur LDAP
Le serveur LDAP vérifie et répond OK/Fail
PostgreSQL autorise ou refuse la connexion

Configuration

1. Dans pg_hba.conf

# Simple LDAP bind
host    all    all    0.0.0.0/0    ldap ldapserver=ldap.company.com ldapbasedn="dc=company,dc=com"

# Avec préfixe/suffixe (pour Active Directory)
host    all    all    0.0.0.0/0    ldap ldapserver=ad.company.com ldapprefix="COMPANY\" ldapsuffix="@company.com"

# LDAP over SSL (recommandé)
host    all    all    0.0.0.0/0    ldap ldapserver=ldap.company.com ldapport=636 ldaptls=1 ldapbasedn="ou=users,dc=company,dc=com"

Paramètres principaux :

Paramètre	Description	Exemple
`ldapserver`	Adresse du serveur LDAP	`ldap.company.com`
`ldapport`	Port (389 standard, 636 SSL)	`636`
`ldapbasedn`	Base DN de recherche	`dc=company,dc=com`
`ldapbinddn`	DN pour la connexion au LDAP	`cn=pgadmin,dc=company,dc=com`
`ldapbindpasswd`	Mot de passe pour ldapbinddn	`SecretPassword`
`ldapsearchattribute`	Attribut de recherche	`uid` (défaut) ou `sAMAccountName` (AD)
`ldaptls`	Activer TLS	`1` (recommandé)
`ldapprefix`	Préfixe du login	`COMPANY\` (pour AD)
`ldapsuffix`	Suffixe du login	`@company.com`

Modes d'authentification LDAP

Mode 1 : Simple Bind (Recommandé)

Le plus simple et le plus sécurisé.

host all all 0.0.0.0/0 ldap ldapserver=ldap.company.com ldapbasedn="dc=company,dc=com"

Fonctionnement :

L'utilisateur tape : username = alice, password = secret123
PostgreSQL tente un bind LDAP avec uid=alice,ou=users,dc=company,dc=com
Si le bind réussit ⇒ authentification OK

Mode 2 : Search + Bind

Plus flexible, permet de rechercher l'utilisateur d'abord.

host all all 0.0.0.0/0 ldap \
    ldapserver=ldap.company.com \
    ldapbasedn="dc=company,dc=com" \
    ldapbinddn="cn=pgadmin,dc=company,dc=com" \
    ldapbindpasswd="AdminSecret" \
    ldapsearchattribute="sAMAccountName"

Fonctionnement :

PostgreSQL se connecte au LDAP avec le compte de service (ldapbinddn)
Recherche l'utilisateur par attribut (sAMAccountName=alice)
Récupère le DN complet : CN=Alice Smith,OU=Users,DC=company,DC=com
Tente un bind avec ce DN et le password fourni par l'utilisateur

Exemple avec Active Directory

Configuration typique :

# pg_hba.conf pour Active Directory
host    all    all    10.0.0.0/8    ldap \
    ldapserver=ad.company.com \
    ldapport=636 \
    ldaptls=1 \
    ldapbasedn="DC=company,DC=com" \
    ldapbinddn="CN=PostgreSQL Service,OU=ServiceAccounts,DC=company,DC=com" \
    ldapbindpasswd="ServiceAccountPassword" \
    ldapsearchattribute="sAMAccountName" \
    ldapsearchfilter="(&(objectClass=user)(memberOf=CN=DBUsers,OU=Groups,DC=company,DC=com))"

Explication :

ldapserver=ad.company.com : Contrôleur de domaine Active Directory
ldapport=636 + ldaptls=1 : Connexion sécurisée (LDAPS)
ldapsearchattribute="sAMAccountName" : Attribut username Windows
ldapsearchfilter : Filtre pour n'autoriser que les membres du groupe DBUsers

Création automatique d'utilisateurs

⚠️ Point important : LDAP authentifie mais ne crée pas l'utilisateur dans PostgreSQL.

Vous devez :

Créer manuellement les utilisateurs :

CREATE USER alice;
GRANT CONNECT ON DATABASE mydb TO alice;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO alice;

Ou utiliser un script de synchronisation :

#!/bin/bash
# Synchroniser les utilisateurs LDAP vers PostgreSQL
ldapsearch -x -H ldap://ldap.company.com -b "ou=users,dc=company,dc=com" \
    -s sub "(objectClass=user)" uid | \
grep "^uid:" | \
awk '{print $2}' | \
while read user; do
    psql -c "CREATE USER IF NOT EXISTS $user;"
    psql -c "GRANT pg_read_all_data TO $user;"
done

Avantages de LDAP

Centralisation :
- Un seul mot de passe pour tous les services
- Désactivation d'un compte ⇒ révocation immédiate partout
Conformité :
- Politique de mots de passe centralisée
- Audit unifié
Gestion simplifiée :
- Pas besoin de gérer les mots de passe dans PostgreSQL
- Rotation automatique via AD
Intégration avec IAM :
- SSO possible (avec Kerberos)
- MFA via AD

Inconvénients

Dépendance externe :
- Si le LDAP est down, plus de connexions possibles
- Latence réseau sur chaque authentification
Complexité :
- Configuration plus technique
- Dépannage plus difficile
Performance :
- Chaque connexion fait une requête LDAP
- Utiliser un connection pooler (PgBouncer) pour mitiger

Bonnes pratiques

Toujours utiliser LDAPS (port 636) :
```
ldapport=636 ldaptls=1
```

Utiliser un compte de service dédié pour les recherches :

ldapbinddn="CN=PG Service,OU=Services,DC=company,DC=com"

Filtrer par groupe de sécurité :

ldapsearchfilter="(memberOf=CN=DatabaseUsers,OU=Groups,DC=company,DC=com)"

Connection pooling obligatoire :
- PgBouncer ou PgPool pour limiter les requêtes LDAP

Compte de secours local :

# pg_hba.conf
local   all   postgres   peer              # Admin local
host    all   all        0.0.0.0/0  ldap   # Utilisateurs LDAP

Monitoring des échecs :

# postgresql.conf
log_connections = on
log_failed_connections = on

Comparatif et Recommandations

Matrice de décision

Contexte	Méthode recommandée	Justification
Développement local	`trust` (local only)	Simplicité
Développement partagé	`scram-sha-256`	Sécurité de base
Production standard	`scram-sha-256` + SSL	Standard industriel
Haute sécurité	`cert`	Pas de mot de passe
Applications M2M	`cert`	Automatisation
Entreprise avec AD	`ldap` (+ MFA)	Centralisation
Environnement régulé	`cert` ou `ldap` + audit	Conformité

Chemins de migration recommandés

Migration 1 : md5 → scram-sha-256 (Prioritaire)

1. postgresql.conf : password_encryption = 'scram-sha-256'
2. Restart PostgreSQL
3. pg_hba.conf : md5 → scram-sha-256
4. Reload configuration
5. Réinitialiser les mots de passe utilisateurs
6. Vérifier les logs pour échecs d'authentification

Migration 2 : password/trust → scram-sha-256

1. Identifier tous les usages de trust/password
2. Créer des utilisateurs avec mots de passe
3. Tester la connexion avec scram-sha-256
4. Remplacer progressivement dans pg_hba.conf
5. Reload et surveiller

Migration 3 : Aucune auth → LDAP (Grandes entreprises)

1. Auditer l'existant
2. Définir le mapping utilisateurs LDAP ↔ PostgreSQL
3. Configurer LDAPS sur un serveur de test
4. Créer les utilisateurs PostgreSQL
5. Tester l'authentification
6. Déploiement progressif (par application)
7. Migration complète
8. Désactivation des anciennes méthodes

Sécurisation multi-niveaux (Approche défense en profondeur)

# pg_hba.conf - Exemple production sécurisé

# 1. Admin local uniquement (peer = utilisateur système)
local   all   postgres   peer

# 2. Comptes applicatifs M2M avec certificats
hostssl myapp appuser   10.0.1.0/24   cert   clientcert=verify-full

# 3. Utilisateurs entreprise via LDAP (réseau interne)
hostssl all   all        10.0.0.0/8    ldap   ldapserver=ad.company.com ldapport=636 ldaptls=1

# 4. Utilisateurs externes avec SCRAM + SSL (VPN)
hostssl all   external   192.168.100.0/24   scram-sha-256

# 5. Deny all (explicite)
host    all   all        0.0.0.0/0     reject

Dépannage et Diagnostics

Problèmes courants

1. "FATAL: password authentication failed"

Causes possibles :

Mauvais mot de passe
Utilisateur n'existe pas
Hash de mot de passe incompatible (md5 vs scram)

Diagnostic :

-- Vérifier l'utilisateur existe
SELECT * FROM pg_authid WHERE rolname = 'alice';

-- Vérifier le type de hash
SELECT rolname,
       substring(rolpassword, 1, 10) as hash_prefix
FROM pg_authid  
WHERE rolname = 'alice';

2. "FATAL: no pg_hba.conf entry for host"

Cause : La connexion ne correspond à aucune règle dans pg_hba.conf

Diagnostic :

# Vérifier la configuration
cat /var/lib/postgresql/data/pg_hba.conf | grep -v "^#" | grep -v "^$"

# Tester depuis le client
psql -h pg.example.com -U alice -d mydb

Solution : Ajouter une règle correspondante et recharger :

pg_ctl reload

3. LDAP : "LDAP authentication failed"

Causes :

Serveur LDAP inaccessible
DN incorrect
Attributs de recherche mal configurés

Diagnostic :

# Tester la connexion LDAP manuellement
ldapsearch -x -H ldap://ldap.company.com \
           -D "cn=admin,dc=company,dc=com" \
           -w AdminPassword \
           -b "dc=company,dc=com" \
           "(uid=alice)"

# Vérifier les logs PostgreSQL
tail -f /var/log/postgresql/postgresql-16-main.log | grep -i ldap

4. Certificats : "certificate verify failed"

Causes :

Certificat expiré
CA non reconnue
Nom (CN) ne correspond pas

Diagnostic :

# Vérifier la validité du certificat
openssl x509 -in alice.crt -noout -dates -subject

# Tester la connexion SSL
openssl s_client -connect pg.example.com:5432 -starttls postgres

# Vérifier les permissions
ls -la ~/.postgresql/
# postgresql.key doit être 600 (rw-------)

Tests et Validation

Script de test d'authentification

#!/bin/bash
# test_auth.sh - Tester les différentes méthodes

echo "=== Test SCRAM-SHA-256 ==="  
PGPASSWORD=SecurePass psql -h localhost -U alice -d postgres -c "SELECT current_user;"  

echo "=== Test avec certificat ==="  
psql "host=localhost user=bob dbname=postgres sslmode=verify-full sslcert=~/.postgresql/bob.crt sslkey=~/.postgresql/bob.key" -c "SELECT current_user;"  

echo "=== Test trust (local) ==="  
psql -U postgres -d postgres -c "SELECT current_user;"  

echo "=== Test LDAP (simulé avec compte) ==="  
PGPASSWORD=LDAPPassword psql -h ldap-pg.example.com -U charlie -d postgres -c "SELECT current_user;"

Vérification de la configuration

-- Lister les utilisateurs et leur type d'auth
SELECT
    rolname,
    CASE
        WHEN rolpassword IS NULL THEN 'No password'
        WHEN rolpassword LIKE 'SCRAM-SHA-256%' THEN 'SCRAM-SHA-256'
        WHEN rolpassword LIKE 'md5%' THEN 'MD5 (deprecated)'
        ELSE 'Unknown'
    END as auth_method,
    rolcanlogin as can_login,
    rolvaliduntil as valid_until
FROM pg_authid  
WHERE rolcanlogin = true  
ORDER BY rolname;

Nouveautés PostgreSQL 18 (Septembre 2025)

1. Support OAuth 2.0

PostgreSQL 18 introduit le support expérimental d'OAuth 2.0 pour l'authentification.

# Nouveau dans pg_hba.conf
host    all    all    0.0.0.0/0    oauth \
    oauth_issuer_url="https://auth.company.com" \
    oauth_audience="postgresql-cluster" \
    oauth_scope="openid profile email"

Avantages :

SSO moderne (Google, Azure AD, Okta)
Tokens JWT au lieu de mots de passe
Révocation centralisée

2. SCRAM Passthrough (postgres_fdw, dblink)

Possibilité de passer l'authentification SCRAM à travers les connexions fédérées.

-- Avant PG 18 : Fallback sur password en clair
-- Après PG 18 : SCRAM préservé

CREATE SERVER remote_pg FOREIGN DATA WRAPPER postgres_fdw  
OPTIONS (host 'remote.pg.com', dbname 'remotedb',  
         scram_channel_binding 'require');

3. Configuration TLS 1.3 avancée

Nouveau paramètre ssl_tls13_ciphers pour contrôler finement les ciphers TLS 1.3.

# postgresql.conf
ssl_min_protocol_version = 'TLSv1.3'  
ssl_tls13_ciphers = 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'

4. Mode FIPS (Federal Information Processing Standards)

Support du mode FIPS pour conformité gouvernementale US.

# postgresql.conf
ssl_fips_mode = 'on'  # Nouveau paramètre

Ressources et Documentation

Documentation officielle

PostgreSQL Authentication : https://www.postgresql.org/docs/18/auth-methods.html
pg_hba.conf : https://www.postgresql.org/docs/18/auth-pg-hba-conf.html
SSL/TLS : https://www.postgresql.org/docs/18/ssl-tcp.html

Outils

pgAdmin : Interface graphique avec gestion des connexions
DBeaver : Client universel supportant tous les types d'auth
pgBouncer : Connection pooler essentiel avec LDAP

Communauté

Mailing list pgsql-general : Aide sur les problèmes d'authentification
Stack Overflow : Tag postgresql + authentication
PostgreSQL Wiki : https://wiki.postgresql.org/wiki/Client_Certificate_Authentication

Conclusion

Le choix de la méthode d'authentification est une décision critique qui impacte la sécurité, la facilité de gestion, et la conformité de votre système PostgreSQL.

Récapitulatif des recommandations :

✅ Pour 90% des cas : scram-sha-256 + SSL/TLS
✅ Pour les applications : cert (certificats clients)
✅ Pour les grandes entreprises : ldap (Active Directory)
❌ À éviter absolument : trust (hors dev local), password, md5

Prochaine étape recommandée : Si vous utilisez encore md5, planifiez dès maintenant la migration vers scram-sha-256. La sécurité de vos données en dépend.

⏭️ Nouveauté PG 18 : Authentification OAuth 2.0

FilesExpand file tree

02.1-methodes-authentification.md

Latest commit

History

02.1-methodes-authentification.md

File metadata and controls

16.2.1. Méthodes d'Authentification PostgreSQL

Introduction

Vue d'ensemble des méthodes

1. La méthode trust : Confiance Aveugle

Concept

Fonctionnement

Quand l'utiliser ?

Exemple pratique

Risques

2. La méthode password : Mot de Passe en Clair

Concept

Fonctionnement

Pourquoi est-elle obsolète ?

Statut actuel

❌ Ne l'utilisez jamais

3. La méthode md5 : Le Hachage (Déprécié)

Concept

Fonctionnement

Analogie pour débutants

Pourquoi est-elle dépréciée ?

Exemple d'attaque

Statut actuel (PostgreSQL 18)

Migration de md5 vers scram-sha-256

4. La méthode scram-sha-256 : Le Standard Moderne ✅

Concept

Fonctionnement

Pourquoi est-elle supérieure ?

1. Résistance aux attaques par force brute

2. Protection contre le rejeu (replay attacks)

3. Authentification mutuelle

4. Salt unique par utilisateur

5. Compatibilité avec les normes

Configuration

Création d'utilisateur avec SCRAM

Migration complète vers SCRAM

Compatibilité clients

Bonnes pratiques

5. La méthode cert : Authentification par Certificat

Concept

Principe de fonctionnement

Architecture

Configuration

Connexion côté client

Avantages

Inconvénients et défis

Cas d'usage typiques

Combinaison avec SCRAM

6. La méthode ldap : Intégration Entreprise

Concept

Fonctionnement

Configuration

Modes d'authentification LDAP

Mode 1 : Simple Bind (Recommandé)

Mode 2 : Search + Bind

Exemple avec Active Directory

Création automatique d'utilisateurs

Avantages de LDAP

Inconvénients

Bonnes pratiques

Comparatif et Recommandations

Matrice de décision

Chemins de migration recommandés

Sécurisation multi-niveaux (Approche défense en profondeur)

Dépannage et Diagnostics

Problèmes courants

1. "FATAL: password authentication failed"

2. "FATAL: no pg_hba.conf entry for host"

3. LDAP : "LDAP authentication failed"

4. Certificats : "certificate verify failed"

Tests et Validation

Script de test d'authentification

Vérification de la configuration

Nouveautés PostgreSQL 18 (Septembre 2025)

1. Support OAuth 2.0

1. La méthode `trust` : Confiance Aveugle

2. La méthode `password` : Mot de Passe en Clair

3. La méthode `md5` : Le Hachage (Déprécié)

4. La méthode `scram-sha-256` : Le Standard Moderne ✅

5. La méthode `cert` : Authentification par Certificat

6. La méthode `ldap` : Intégration Entreprise