Subject: Re: Some thoughts about SCRAM implementation
To: Andres Freund <andres@anarazel.de>
References: <df8c6e27-4d8e-5281-96e5-131a4e638fc8@8kdata.com>
 <a990783c-44b3-cff6-7128-c6393be41af6@iki.fi>
 <729b548a-f434-f31c-15e7-59f44aaecc8d@8kdata.com>
 <20170410183230.oxagjpfgj6xxmcwx@alap3.anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: =?UTF-8?Q?=c3=81lvaro_Hern=c3=a1ndez_Tortosa?= <aht@8kdata.com>
Message-ID: <fd4530e0-f016-4eb9-a0d0-e32824482db5@8kdata.com>
Date: Tue, 11 Apr 2017 14:53:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170410183230.oxagjpfgj6xxmcwx@alap3.anarazel.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 10/04/17 20:32, Andres Freund wrote:
> On 2017-04-10 20:28:27 +0200, Álvaro Hernández Tortosa wrote:
>>
>> On 10/04/17 13:02, Heikki Linnakangas wrote:
>>> On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa 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.
>>> We missed the boat for PostgreSQL 10. You're right that it probably
>>> wouldn't be difficult to implement, but until there's a concrete patch
>>> to discuss, that's a moot point.
>>      Really? That's a real shame.... I know we're very late in the CF cycle
>> but, again, this would be a real shame.
> That can equally be said about about a lot of features.  If we don't
> stop at some point... Also, we're not late in the CF cycle, the CF cycle
> for v10 is over.  It's not like the non-existance of channel binding
> removes previously existing features, or makes SCRAM useless.
>
>
> Greetings,
>
> Andres Freund

     I know this is a lost battle. But please bear with me for a minute.

     Let's put ourselves on the foot of potential users. Why would 
anyone want to use SCRAM? What for? The hashing mechanism is better, no 
question. And bring some added benefits, true. So its "better". But the 
real gain comes from using channel binding, which avoids impersonation, 
MITM attacks. This is the deal breaker. SCRAM without channel binding is 
like Coke Zero without caffeine and mixed with water. Don't get me 
wrong, the work behind is great.

     But just a bit more is needed to make it really a big announcement 
and provide real value to (I guess, mostly but very interesting) 
enterprise customers, for which MITM and impersonating are big things. 
The good news is that adding channel binding is like inverse Paretto: a 
20% of extra effort (I bet significantly less) leads to 80% improvement.

     So CF v10 is over. So we're on testing phase. Can't we consider 
this a "missing feature bug"? ^_^


     Á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