Postgresql – Postgres 13 – how to downgrade password requirements

postgresql

I have a MS .net application that needs to access a postgres database that's been recently upgraded to v13.

I'm using the Npgsql library (very old version) and get the error Only AuthenticationClearTextPassword and AuthenticationMD5Password supported for now. Received: 10

The suggestion from this post is to comment-out the line password_encryption in the file postgresql.conf and then re-set the users passwords ALTER USER ???? PASSWORD '1234'. I try this and get the same error, I also tried ALTER USER ???? UNENCRYPTED PASSWORD '1234' but this option isn't available anymore.

The basic problem seems to be that postgres 13 wants a level of security that the Npgsql library can't cope with. I can't upgrade Npgsql (not my choice!), so unless I can downgrade the password requirements I'm going to have to regress to an earlier version of postgres

I've tried setting password_encryption = scram-sha-256 also password_encryption = md5 and I've tried commenting-out the whole line. Each time I make the change I run SELECT pg_reload_conf() (as per the comments in the file) and then reset the passwords before trying to log on again. Same error every time.


ok, just found a cure that will fix the immediate problem. I've edited the pg_hba.conf file (thanks @jjanes) and changed the METHOD from scram-sha-256 to md5. This seems to work.

Best Answer

An attacker can try to enumerate which users exist by attempting to log in as a bunch of different user names and seeing what error message is reported, or how long it took to report the error message (or in some cases, how much power the server used before reporting the error or how much noise it made or things like that) for each username. This can be useful to the attacker because he can then not waste time guessing passwords on for users which don't exist, or can spearphish for users which he knows do exist.

To make user enumeration hard, PostgreSQL goes through a mock authentication if pg_hba says scram authentication is needed but the requested username doesn't exist; or if the user does exist but either has no password set or has a password stored in the wrong format. The point of a mock authentication of course is that the client doesn't know it is mock. So if the client doesn't support scram but scram is required by pg_hba, then you get this error message, regardless of how the password is actually stored.