Skip to main content

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:

LineWhat it means for this finding
hostnosslThe connection is never encrypted. The password is readable on the path.
hostsslTLS protects it in transit. A weak method, not an exposed credential.
hostEither, depending on the server's ssl setting — which this rule does not read.
localIt 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.

  • 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.