I have several services (Postfix, Apache (PHP)) that access a PostgreSQL database on a Debian Linux 10 system.

  • everyone is on the same host
  • they use the loopback interface ( to communicate
  • the accessing services store the db user and db password in plain in configuration files
    • owned by root:(service) and mode 640

By default PostgreSQL (in pg_hba.conf) is set to use MD5 for password hashing. I was about to upgrade to scram-sha-256 but then realized that any hashing is most likely meaningless.

Threat Analysis

AFAICS there are three attack points and nowhere does hashing provide any extra security:

  1. the accessing service: It stores the password in plaintext anyway, no hashing is applied here.
  2. communication channel (loopback): Is "sufficiently" secure. Any breach here would mean kernel access level which could also read the password stored in the configuration file of the service itself.
  3. PostgreSQL server: Does not need the password. Any breach here could just access the data.

The passwords are not reused anywhere, so knowing the password does not yield any other access.


Can I switch to plaintext password authentication in ph_hba.conf without any loss in security?

  • Good threat assessment. What do you think you would gain by reducing or not improving the hashing strength of your server? I can't see any advantages. – Pedro May 6 '20 at 6:05
  • 1
    In case a client (e.g. web application) does not persist a connection, each HTTP request could lead to several db connections and each would necessitate a password hashing, increasing latency for that request. While I have not benchmarked scram-sha-256, I know that argon2id typically aims to take 100 ms. So without any loss in security I possibly could gain a lower latency for requests. – problemofficer May 6 '20 at 6:20
  • Ah, so you are seeking to improve latency (might be useful to add to the original question). I can see how improving the hash strength would have a negative effect. You could try persistent or polled connections for this purpose (not sure there's anything that can do this easily for you though)? On a tangent, have you tried using local unix sockets as opposed to TCP/IP? Might give you another incremental advantage? – Pedro May 6 '20 at 6:45
  • 1
    A theat occurs if hacker manage to read the passwords in the pgsql (say, from an injection in an application) and hack an application. Now, they have clear passwords of all SQL accounts, plus an application running on localhost, so they may log into any SQL account in no time. I don't think dropping hashes would make any performance change (tho you may try and benchmark for curiosity). – Xenos May 6 '20 at 16:01
  • @Xenos The db users that the services use do not have the privileges to view pg_shadow which stores the password(hashes), but still that is a potential attack vector I did not think of. – problemofficer May 6 '20 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.