Re: [HACKERS] Some thoughts about SCRAM implementation - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Some thoughts about SCRAM implementation
Date
Msg-id CAB7nPqTX+EkDjW=PrTNXTCysdCG1x9m8waQQm9-gk2fxM6V=Wg@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Some thoughts about SCRAM implementation  (Álvaro Hernández Tortosa <aht@8kdata.com>)
List pgsql-hackers
On Mon, Apr 10, 2017 at 6:39 PM, Álvaro Hernández Tortosa
<aht@8kdata.com> wrote:
> - I think channel binding support should be added. SCRAM brings security
> improvements over md5 and other simpler digest algorithms. But where it
> really shines is together with channel binding. This is the only method to
> prevent MITM attacks. Implementing it should not very difficult. There are
> several possible channel binding mechanisms, but the mandatory and probably
> more typical one is 'tls-unique' which basically means getting the byte
> array from the TLSfinish() message and comparing it with the same data sent
> by the client. That's more or less all it takes to implement it. So I would
> go for it.

I was just looking at that during a long flight, and OpenSSL offers
SSL_get_finished() and SSL_get_peer_finished() to get the Finished
message data. So that's a matter of saving it in the client, encode it
in base64 (the spec is clear about that) and send the data as part of
the first challenge response to the server that just compares both
contents. Of course the protocol list and the first client message
need to be extended as well, but most of the facility is already
there. The spec is also clear about the lines to follow should the
client and/or server be built without OpenSSL (aka no channel binding
support).
--
Michael



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Improve logical decoding error message (was wal_level> WAL_LEVEL_LOGICAL)
Next
From: Vaishnavi Prabakaran
Date:
Subject: Re: [HACKERS] Error-like LOG when connecting with SSL for password authentication