Authentication Methods - MD5, SCRAM-SHA-256, password, trust, peer, ident, cert

 In PostgreSQL, an authentication method defines how a client proves its identity to the database server during connection.

We have multiple authentication methods available in Postgres -

1. MD5 Authentication

md5 is the older PostgreSQL password authentication method.

When we set:

local   all   all   md5

PostgreSQL stores the user password like this:

md5<md5(username + password)>

Pros

• Supported by all old PostgreSQL clients.

• Easy to set up.

Cons (VERY IMPORTANT)

• Old and weak hashing.

• MD5 is vulnerable to:

○ hash collisions

○ brute force attacks

○ replay attacks

MD5 is deprecated, but still available for compatibility.

2. SCRAM-SHA-256 Authentication (Recommended)

scram-sha-256 is the modern, secure password authentication introduced in PostgreSQL 10.

When we set:

local   all   all   scram-sha-256

PostgreSQL stores passwords using:

Salted, hashed, iterative SHA-256 (RFC 5802 & RFC 7677)

Example stored format:

SCRAM-SHA-256$iterations:salt$data

Pros

• MUCH stronger security

• Uses salted, iterated hashing

• Resistant to:

○ brute force attacks

○ rainbow table attacks

○ replay attacks

• Password never sent in clear or reusable form

• Industry standard authentication

Cons

• Very old clients (PostgreSQL <10) do not support SCRAM.

Important Difference

MD5

• Server stores MD5-hashed password.

• Client sends MD5-hash of hash (double hash).

• Vulnerable to interception and cracking.

SCRAM-SHA-256

• Server stores a salted hash.

• Client and server perform a challenge–response exchange.

• Password is NEVER sent or derivable.

Much safer authentication handshake.

3. Password

local / host   all   all   password

What it does - 

Client sends the raw, plain-text password to PostgreSQL.

Bad because:

• Password goes over the network unencrypted (unless using SSL).

• Very insecure.

• Rarely recommended.

Use only for testing.

4. peer (local connections only)

local   all   all   peer

What it does

Checks Linux OS username == PostgreSQL database username.

Example:

• OS user: postgres

• DB user: postgres → login works

• OS user: ubuntu

• DB user: user1 → FAILS

Problem:

Users must exist in Linux system.

You cannot \c db user1 from psql unless you are OS user user1.

Note - Use only on local servers where OS users map to DB users (rare in production).

5. ident (remote equivalent of peer)

host   all   all   0.0.0.0/0   ident

What it does -

Checks username using an external ident server.

Note -  Not commonly used today. Most systems don’t run ident servers. Complicated and outdated.

        Avoid unless we have a special ident-based setup.

6. trust

local / host   all   all   trust

What it does

Allows anyone to connect without a password.

Extremely insecure

Whoever can reach the server can log in as any DB user.

Use ONLY for:

• Dev VM

• Inside Docker container

• Local development

Never use in production.

7. cert (SSL certificate authentication)

hostssl   all   all   0.0.0.0/0   cert

What it does

User authenticates using an SSL client certificate, not a password.

Requirements:

• SSL enabled

• Client presents valid certificate

• Common Name (CN) must match DB username

Most secure option for enterprises

Used in:

• Banking

• Secure corporate networks

• Zero-trust environments