In PostgreSQL’s pg_hba.conf:
local all all trust
host all all 0.0.0.0/0 trust
trust = allow ANYONE to connect with NO password.
Literally:
- Any local user → can log into ANY database as ANY role
- A hacked PHP script → immediate full database access
- A compromised Ubuntu account → total DB control
- If you accidentally open port 5432 → entire world can connect freely
- No password, no authentication, nothing
- A bot scanning IPs could instantly log in**
It’s equivalent to:
“Leave your laptop on the street unlocked, with all your files open.”
❌ Why “trust” is extremely dangerous
1. If a local user gets compromised, DB is gone
If someone gets shell access (or malware runs locally), they can run:
psql -U postgres
→ Instant full control.
2. If 5432 accidentally gets exposed in firewall
Your server becomes fully open:
psql -h yourserver -U postgres
→ No password required → total takeover → complete data breach.
3. Scripts can impersonate any DB user
If you use trust, a script or malware can run:
psql -U admin
psql -U iotadmin
Even if you intended to keep secrets, nothing is protected.
4. It breaks security architecture
Your IoT platform:
- Stores users
- Stores devices and API keys
- Stores telemetry (sensitive industrial data)
- Stores subscription and billing information
All of this must be protected.
🟢 Is TRUST ever useful?
Yes — but ONLY in one scenario:
⚠️ Local test environment on your laptop, NOT a server
When:
- You’re learning PostgreSQL locally
- No external access
- No sensitive data
- Not a VPS
Then you can use trust briefly.
But never on a VPS, even if firewall is configured, because:
- Mistakes happen
- Ports get opened accidentally
- Config changes get forgotten
- Tools temporarily expose services
And bots scan the internet constantly.
🟢 Correct safe authentication method for your VPS
Use scram-sha-256 (recommended, modern, secure).
Your lines should be:
local all all scram-sha-256
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
This means:
- Local connections → must use password
- TCP connections → must use password
- No accidental open access
- Secure even if server is compromised
🛡️ Recommendation (for your exact situation):
✔️ DO NOT use trust
✔️ Continue with scram-sha-256
✔️ Keep iotadmin password-protected
✔️ Keep database isolated inside server (no 5432 open)
You are building a real SaaS product for paying customers → you must follow proper security standards.
🎯 Final Answer:
Trust is not secure. Do not use it on a VPS. Use scram-sha-256.
If you want, I can show you a safe-but-convenient configuration where:
postgresusespeer- Your project users use
scram-sha-256 - No weak methods are used
Just ask:
Show me the safest and simplest pg_hba.conf configuration.elow is the safest, simplest, and industry-recommended PostgreSQL pg_hba.conf configuration for a VPS running multiple projects — just like yours.
This configuration protects your database from:
- Unauthenticated access
- Local privilege escalation
- External attacks
- Accidental port exposure
- Misbehaving scripts
and ensures that only authenticated users, through passwords, can connect.
✅ THE SAFEST + SIMPLEST pg_hba.conf CONFIGURATION
Copy exactly these lines (this is the final recommended config):
# Allow postgres system user to access DB without password (safe)
local all postgres peer
# All other local users must authenticate via password
local all all scram-sha-256
# Allow local TCP connections (127.0.0.1 / ::1) using passwords
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
# Replication (rarely needed) - keep safe
local replication postgres peer
host replication postgres 127.0.0.1/32 scram-sha-256
host replication postgres ::1/128 scram-sha-256
🧠 Why This Is the Best Setup
✔️ 1. postgres uses peer authentication
Only the Linux postgres user can log in without a password.
This is safe because:
- It works only on the server itself
- The postgres Linux user is rarely used
- It prevents password leaks for the system admin user
- Still allows easy local admin work (if ever needed)
✔️ 2. ALL other roles (like iotadmin) must use passwords
This is the core security rule.
Whether connecting via:
- Socket (
psql -U iotadmin -d iotdb) - TCP (
psql -U iotadmin -h 127.0.0.1 -d iotdb)
They must authenticate using password.
No exceptions.
✔️ 3. Only LOCAL connections allowed (no remote DB access)
This ensures:
- No outside device or hacker can even reach PostgreSQL
- Even if UFW firewall becomes misconfigured, the DB still rejects all remote IPs
✔️ 4. Uses scram-sha-256 — the modern secure hashing
More secure than:
md5(old and weak)password(plaintext — NEVER use)
✔️ 5. Replication allowed only for postgres (optional + safe)
Most users don’t use replication — but this keeps the option open.
🔥 BONUS — What Your Security Posture Looks Like Now
With:
- UFW blocking port 5432 externally
- pg_hba.conf rejecting external incoming connections
- All project roles using strong SCRAM passwords
- Only postgres using peer authentication
Your PostgreSQL is now:
🛡️ Secure against local privilege escalation
🔒 Secure against external attackers
❌ Immune to trust authentication mistakes
🌐 Not exposed to the internet
📦 Perfect for multiple isolated project databases
This is the same configuration used in financial, scientific, and IoT production systems.
🧩 Next Step
Now modify the file:
sudo nano /etc/postgresql/*/main/pg_hba.conf
Replace the relevant lines with the configuration I provided.
Then apply the changes:
sudo systemctl restart postgresql
Test:
psql -U iotadmin -d iotdb
It should prompt:
Password for user iotadmin: