Secure PostgreSQL authentication

Reviewed on October 2, 2026 · View on GitHub

The PostgreSQL managed service includes security mechanisms to protect connections and data. This page presents the best practices for securing authentication, in particular in a SecNumCloud compliance context.

The PostgreSQL cluster is encrypted and secured by default.

Secure SSL/TLS connections

All connections to the PostgreSQL cluster are encrypted with TLS (Transport Layer Security). The SSL protocol is mandatory for all external connections.

Verify TLS encryption

Connect with the sslmode=require mode to guarantee an encrypted connection:

psql "host=<host> port=5432 dbname=<database> user=<user> sslmode=require"

SSL verification levels

Mode	Description
sslmode=require	Encrypted connection without server certificate verification
sslmode=verify-ca	Verifies that the server certificate is signed by a trusted authority
sslmode=verify-full	Verifies the certificate and the host name

For maximum security:

psql "host=<host> port=5432 dbname=<database> user=<user> sslmode=verify-full"

Password encryption

The PostgreSQL service uses SCRAM-SHA-256 encryption for passwords. This mechanism offers better security than the older MD5 encryption.

SCRAM-SHA-256 characteristics

• passwords are never transmitted in clear text over the network;
• protection against replay attacks;
• resistance to dictionary attacks.

SCRAM-SHA-256 encryption is enabled by default on all managed PostgreSQL clusters.

Strong authentication and SecNumCloud compliance

To meet SecNumCloud requirements regarding strong authentication, combine several layers of security.

Recommended multi-factor architecture

Factor	Mechanism	Protection
Something you know	Password (SCRAM-SHA-256)	PostgreSQL authentication
Something you have	Client certificate or VPN access	Network layer
Something you are	Network access control (IP, VPC)	Security perimeter

Recommended configuration for sensitive environments

1. Access via a private network: connect your applications through a VPN or a VPC (Virtual Private Cloud) to limit the exposure of the cluster;

2. IP restriction: limit access to the authorized IP address ranges;

3. Credential rotation: change application passwords regularly (see Manage users and roles).

Multi-factor authentication (MFA)

PostgreSQL does not provide native MFA. To implement multi-factor authentication, use a layered architecture.

Recommended MFA approach

Layer	Mechanism	Factor
Layer 1	PostgreSQL password	Something you know
Layer 2	VPN with MFA	Something you have
Layer 3	Client certificate	Something you have
Layer 4	IP/VPC restriction	Something you are

MFA configuration via a bastion

To implement MFA, install a bastion with strong authentication:

1. SSH bastion with MFA:

   • deploy an SSH bastion with MFA support (TOTP, hardware key);
   • configure the PostgreSQL connection only through the bastion.

2. Access via a VPN with MFA:

   • configure a VPN with MFA authentication;
   • limit access to the PostgreSQL cluster to clients connected to the VPN.

Typical MFA architecture

[User] 
    → [VPN with MFA] 
    → [SSH bastion] 
    → [PostgreSQL cluster]

Client certificates (mutual TLS authentication)

PostgreSQL supports client certificate authentication. This feature is not configurable through the Numspot API at this time. Contact support to enable this option on critical clusters.

note

Native PostgreSQL multi-factor authentication (client certificates) is not currently configurable through the Numspot API. For strong authentication, use network-level access control (VPN, bastion).

Password policy

Best practices

Apply these rules for PostgreSQL passwords:

• a minimum length of 12 characters;
• a combination of uppercase letters, lowercase letters, numbers and special characters;
• exclusion of dictionary words and personal information;
• regular rotation (every 90 days for privileged accounts).

Create a strong password

CREATE USER <user> WITH PASSWORD '<complex_password>';

Example of a strong password (to be adapted):

Kj7#mP9$vL3@nQ2xWz5!

Set an expiry

For temporary or at-risk accounts:

ALTER USER <user> WITH VALID UNTIL '2026-06-30 23:59:59';

Connection audit

The PostgreSQL cluster logs authentication events to enable auditing and anomaly detection.

Logged events

Event	Description
Successful connection	Record of each connection
Authentication failure	Connection attempts with invalid credentials
Disconnection	End of session

Consult the connection logs

The PostgreSQL logs are available through the observability tools of your cluster. Contact support to access the audit logs.

Protection against attacks

Attempt throttling

The service applies a 5-second delay after each authentication failure to slow down brute-force attacks.

note

The managed PostgreSQL service does not apply automatic blocking after a defined number of connection failures. Protection relies on the delay between attempts and on log monitoring. For automatic blocking based on the number of attempts, use an external tool such as fail2ban or an application firewall.

Anomaly detection

Monitor suspicious behavior in the logs:

• multiple connection failures from the same IP;
• connection attempts at unusual hours;
• access from unauthorized IP ranges.

Block a user in case of misuse

If you detect suspicious activity or a compromised account, you can immediately block a user's access.

Temporarily block an account

Use the NOLOGIN attribute to prevent any connection:

ALTER USER <user> WITH NOLOGIN;

The user can no longer connect, but their permissions and data are kept.

Unblock an account

To re-enable access:

ALTER USER <user> WITH LOGIN;

Check a user's status

SELECT rolname, rolcanlogin FROM pg_roles WHERE rolname = '<user>';

rolcanlogin	Meaning
t (true)	The user can connect
f (false)	The user is blocked

Permanently delete an account

If the account is no longer needed or the compromise is confirmed:

-- Revoke the permissions first
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM <user>;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM <user>;
REVOKE USAGE ON SCHEMA public FROM <user>;

-- Delete the user
DROP USER <user>;

warning

Deletion is irreversible. Verify that no object belongs to this user before deletion.

Incident response procedure

In case of detected misuse (multiple connection failures, suspicious activity):

1. Immediately block the account with ALTER USER ... NOLOGIN;
2. Reset the password if you want to re-enable the account;
3. Analyze the logs to identify the origin of the attack;
4. Restrict network access through security groups or the VPN;
5. Delete the account if necessary.

Revoke or renew a compromised password

If you suspect a compromise, reset the password immediately.

For the primary user

Use the API to reset the password of the primary user:

PUT /postgresql/spaces/{spaceId}/clusters/{clusterId}/password/reset

See Reset the password for more details.

For additional users

ALTER USER <user> WITH PASSWORD '<new_password>';

Summary of SecNumCloud best practices

Requirement	Recommended implementation
Connection encryption	TLS mandatory (sslmode=require minimum)
Strong authentication	Private network (VPN/VPC) + password
Password policy	SCRAM-SHA-256, regular rotation, complexity
Access audit	Connection logs enabled
Access control	Principle of least privilege
Account blocking	ALTER USER ... NOLOGIN in case of suspicious activity
Revocation	Immediate reset in case of compromise

tip

For critical architectures, install an SSH bastion or an access proxy to centralize and audit all connections to the databases.