Authentification method on client side checking
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37074psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 05:56 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37074_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37074_1 && git checkout t37074_1Patchset v1 (message #1) is on t37074_1
Hello,
Despite the addition of SCRAM authentification to PostgreSQL 10, MITM
attack can be performed by saying that the server supports, for example,
only md5 authentication. The possible solution for it is checking
authentification method on a client side and reject connections that
could be unsafe.
Postgresql server can require unencrypted password passing, md5, scram,
gss or sspi authentification.
In the attached patch you can find the solution for it. The new provided
features are the following:
The parameter with acceptable authentification methods can be passed
into connection methods of libpq library.
Also, this parameter can be specified to psql as a command line
argument.
The documentation for command line arguments of psql and arguments of
libpq methods are also presented.
Thank you for attention!
Best,
--
------
Victor Drobny
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 09/07/17 18:47, Victor Drobny wrote:
Hello,
Despite the addition of SCRAM authentification to PostgreSQL 10, MITM
attack can be performed by saying that the server supports, for
example, only md5 authentication. The possible solution for it is
checking authentification method on a client side and reject
connections that could be unsafe.Postgresql server can require unencrypted password passing, md5,
scram, gss or sspi authentification.
Hi Victor.
Precisely yesterday I initiated a similar thread:
/messages/by-id/d4098ef4-2910-c8bf-f1e3-f178ba77c381@8kdata.com
I think that a) the mere auth mechanism is not enough (channel
binding or not, ssl or not, change a lot the effective security
obtained) and b) maybe a categorization is a better way of specifying a
connection security requirements.
What's your opinion on this? Any answer should also be coordinated
among the drivers.
�lvaro
--
�lvaro Hern�ndez Tortosa
-----------
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jul 10, 2017 at 9:29 AM, Álvaro Hernández Tortosa
<aht@8kdata.com> wrote:
Precisely yesterday I initiated a similar thread:
/messages/by-id/d4098ef4-2910-c8bf-f1e3-f178ba77c381@8kdata.comI think that a) the mere auth mechanism is not enough (channel binding
or not, ssl or not, change a lot the effective security obtained) and b)
maybe a categorization is a better way of specifying a connection security
requirements.What's your opinion on this? Any answer should also be coordinated among
the drivers.
Before rushing into implementing something that we may not want, let's
discuss the matter on the thread spawned by Álvaro and find an
agreement and a direction of implementation. I was planning to answer
your message with my own thoughts on the matter. Having more control
in libpq is definitely something that we should have.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers