Re: [HACKERS] SCRAM auth and Pgpool-II - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] SCRAM auth and Pgpool-II
Date
Msg-id 20170708.084240.1800247571793601438.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: [HACKERS] SCRAM auth and Pgpool-II  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> I think it is.  From a security point of view, the fact that the same
> salt is always used for the same username is a weakness of md5
> authentication which SCRAM corrects.

In my understanding, md5 does not always use the same salt for the
same username. PostgreSQL keeps md5(password+username) in
pg_authid. When md5 auth is required, the backend sends a random
number (i.e. salt) to the client. The client replies back
md5(salt+md5(password+username)) to the backend. The backend does the
calculation (md5(salt+md5(password+username))). If the result matches
the value sent from the user, md5 authentication succeeds.

So the salt is differ in each session in md5.

The weakness in md5 is , IMO, each PostgreSQL installation always
keeps the same value (md5(password+username)).

> IIUC, things will get even worse once channel binding is committed,
> presumably for PostgreSQL 11.  The point of channel binding is to
> guarantee that you are conducting the authentication exchange with the
> target server, not some intermediate proxy that might be conducting a
> hostile MITM attack.  pgpool may not be a hostile attack, but it is
> acting as a MITM, and channel binding is going to figure that out and
> fail the authentication.  So unless I'm misunderstanding, the solution
> you are proposing figures to have a very limited shelf life.

Check...

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] SCRAM auth and Pgpool-II
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] SCRAM auth and Pgpool-II