On 11/04/17 15:03, Magnus Hagander wrote:
On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa <a...@8kdata.com <mailto:a...@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
        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
        removes previously existing features, or makes SCRAM useless.


        Andres Freund

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

        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.




Álvaro Hernández Tortosa


Reply via email to