From: Álvaro Hernández Tortosa <aht@8kdata.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Some thoughts about SCRAM implementation
Date: Tue, 11 Apr 2017 15:09:28 +0200
Message-ID: <cab0595b-b0d1-9cfa-c562-d34d94cf09e5@8kdata.com> (raw)
In-Reply-To: <CABUevEw3hn7pJo6Wk7BPP9SdNFKZTpG2_=+p8uTm_92V9u=tXA@mail.gmail.com>
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>
<fd4530e0-f016-4eb9-a0d0-e32824482db5@8kdata.com>
<CABUevEw3hn7pJo6Wk7BPP9SdNFKZTpG2_=+p8uTm_92V9u=tXA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 11/04/17 15:03, Magnus Hagander wrote:
> On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa
> <aht@8kdata.com <mailto:aht@8kdata.com>> wrote:
>
>
>
> 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.
>
>
>
> I think you are seriously undervaluing the SCRAM without channel binding.
I'm not. If I wouldn't appreciate its value, I wouldn't be writing
a client library for the jdbc driver.
> It improves a lot of things over our current md5 method beyond just
> using a stronger hashing algorithm.
>
> Sure, channel binding is great. But that's not a dealbreaker, or even
> close to it.
I think otherwise. It is close to a dealbreaker. And it's so few
extra code lines that it requires....
>
> 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.
>
>
> I would expect most enterprise customers who care about MITM
> protection are already using either TLS or ipsec to cover that
> already. They have benefit from the other parts of SCRAM, but they've
> already solved those problems.
Enterprises use checklists. And discard solutions if they don't
have "checks" on all the items. One of those is, in my opinion, SCRAM
with channel binding. I don't want this to happen to PG, specially when
it's so easy to implement.
But I will conserve my remaining courage (thanks Michael!) credits
for future threads ;) I have stated my opinion clearly, I will now go
back to the client library.
Thanks,
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: aht@8kdata.com, magnus@hagander.net, andres@anarazel.de, hlinnaka@iki.fi
Subject: Re: Some thoughts about SCRAM implementation
In-Reply-To: <cab0595b-b0d1-9cfa-c562-d34d94cf09e5@8kdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox