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.
The host case is answered by the report, not by a second rule
A host … password line on a server whose ssl is off really does put the credential on the wire in
the clear, and that is the worst reading of this table. It does not get a rule of its own. The report
already carries both halves: this finding says the method is cleartext, and
SEC.PG.TLS.DISABLED says the server offers no encryption at all. A third
id would state their conjunction and nothing else — and it would fire on exactly the runs where both
are already listed, which is how a catalog grows findings that repeat each other instead of adding
one.
Read them together: cleartext plus TLS disabled is the exposed case. Either one alone is a weakness with a bounded reading, and each says which.
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.