SEC.AUTH.HBA_CLEARTEXT — The password crosses the wire as typed
- Category: security
- Severity: high
- Level: 0
- Confidence: deterministic
- Downtime class: none — the finding is about how the server authenticates, not about a statement
- Stability: stable
- Suites: audit
- Applies to: PostgreSQL 18
password is not a weaker hash — it is no hash
PostgreSQL's password method transmits the password exactly as the client holds it. Anything on the
path that can read the connection reads the credential itself, and it reads a credential that works
everywhere that role is accepted.
Whether TLS covers it depends on the line and on the server:
| Line | What it means for this finding |
|---|---|
hostnossl | The connection is never encrypted. The password is readable on the path. |
hostssl | TLS protects it in transit. A weak method, not an exposed credential. |
host | Either, depending on the server's ssl setting — which this rule does not read. |
local | It crosses a Unix socket rather than the network. |
SQLens states which of those the line says, and does not guess at the rest: a severity derived from an unread setting is a severity derived from an assumption.
Bad
host all all 10.0.0.0/8 password
Good
hostssl all app 10.0.4.0/24 scram-sha-256
Every supported client library speaks SCRAM, and it never puts the password on the wire — not even without TLS.
Related
SEC.AUTH.HBA_MD5— a different failure: the password is never sent, but the verifier is weak. The two are separate ids because a merged finding would be wrong about whichever half did not apply.