2

Setup

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 (127.0.0.1) 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.

Question

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

5
  • 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
    Commented May 6, 2020 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. Commented May 6, 2020 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
    Commented May 6, 2020 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
    Commented May 6, 2020 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. Commented May 6, 2020 at 19:37

1 Answer 1

0

Yes, you can skip any password hashing for localhost, if you trust every human and process able to get to that host. If it is wise to do so depends on your context, and other security controls in place.

Trust

When 'trust' authentication is specified, PostgreSQL assumes that anyone who can connect to the server is authorized to access the database with whatever database user name they specify. Restrictions made in the database and user columns still apply. This method should only be used when there is adequate operating-system-level protection on connections to the server. restrictions made in the database and user columns still apply. This method should only be used when there is adequate operating-system-level protection on connections to the server.

pg_hba.conf sample:

# Allow any user on the local system to connect to any database with
# any database user name using Unix-domain sockets (the default for local
# connections).
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     trust

# The same using local loopback TCP/IP connections.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             127.0.0.1/32            trust
2
  • 1
    how does this answer the question: ` Can I switch to plaintext password authentication in ph_hba.conf without any loss in security?` exactly? this answer basically just says how to do it, not what the trade offs are or if there is a 'loss in security'.
    – LvB
    Commented Oct 23, 2023 at 12:40
  • 1
    Reflections on trust Commented Oct 23, 2023 at 13:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .