api属性文件中的MD5哈希数据库密码

Question

I have a rest api which talks to Postgres, right now in the properties file of the api we are hardcoding the DB password. so we thought when a user role is created in postgres we can use Md5 hash value(or any other encrypted value which should be decrypted by postgres) for the password...and we can use that value(hased value) in api property file instead of hardcoded one.

My question is can we use that Md5 hash value in api dev property file and when the password is sent over network and tries to connect to postgres Will it (postgres) decrypt to actual password and allows the user to connect to DB without authentication failed?????

Answer 1

TL;DR: you can't store the hashed password in a properties file and use it to authenticate unless the client application can recognise that it's pre-hashed and avoid the second hashing pass.

If the client library does recognise pre-hashed passwords (libpq doesn't), the hashed password can be used as a proxy for the real password. You don't need to know the real password if you know the hash. this means it's also no more secure to store the hashed password in the properties file than it is to store the original password.

The password is salted and hashed again before being sent on the wire so you can't sniff what you see on the wire and use that to authenticate.

---

Looking at the source code, sendAuthRequest in src/backend/libpq/auth.c :

/* Add the salt for encrypted passwords. */
if (areq == AUTH_REQ_MD5)
    pq_sendbytes(&buf, port->md5Salt, 4);

port is struct Port in src/include/libpq/libpq-be.h , which has:

char        md5Salt[4];     /* Password salt */

This is set by ConnCreate in src/backend/postmaster/postmaster.c :

    /*
     * Precompute password salt values to use for this connection. It's
     * slightly annoying to do this long in advance of knowing whether we'll
     * need 'em or not, but we must do the random() calls before we fork, not
     * after.  Else the postmaster's random sequence won't get advanced, and
     * all backends would end up using the same salt...
     */
    RandomSalt(port->md5Salt);

Now, passwords are verified in md5_crypt_verify in src/backend/libpq/crypt.c . There we see that passwords already stored as md5 are hashed again with the session salt:

        if (isMD5(shadow_pass))
        {
            /* stored password already encrypted, only do salt */
            if (!pg_md5_encrypt(shadow_pass + strlen("md5"),
                                port->md5Salt,
                                sizeof(port->md5Salt), crypt_pwd))
            {
                pfree(crypt_pwd);
                return STATUS_ERROR;
            }
        }

Thus the hashed password sent on the wire is protected against replay attacks by the session salt.

---

Whether the client app can recognise a pre-hashed password and the format it expects them to be in depends on the client library.

According to pg_password_sendauth in src/interfaces/libpq/fe-auth.c the libpq front-end doesn't seem to check for pre-hashed password input. Other clients may vary.

Answer 2

Just to be clear - md5 hashing is not encryption.

19.3.2. Password authentication

The password-based authentication methods are md5 and password . These methods operate similarly except for the way that the password is sent across the connection, namely MD5-hashed and clear-text respectively .

If you are at all concerned about password "sniffing" attacks then md5 is preferred. Plain password should always be avoided if possible. However, md5 cannot be used with the db_user_namespace feature. If the connection is protected by SSL encryption then password can be used safely (though SSL certificate authentication might be a better choice if one is depending on using SSL).

PostgreSQL database passwords are separate from operating system user passwords. The password for each database user is stored in the pg_authid system catalog. Passwords can be managed with the SQL commands CREATE USER and ALTER USER, eg, CREATE USER foo WITH PASSWORD 'secret'. If no password has been set up for a user, the stored password is null and password authentication will always fail for that user.

If you configure your Postgres client authentication file ( pg_hba.conf ) for md5 password-based authentication , you don't need to explicitly use md5() function to keep database password in your property file.

For encrypting purposes - you can configure database connection to work over SSL. Please check Secure TCP/IP Connections with SSL .