Re: Some thoughts about SCRAM implementation

On 11/04/17 15:03, Magnus Hagander wrote:
> On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa
> <aht(at)8kdata(dot)com <mailto:aht(at)8kdata(dot)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