Re: [HACKERS] Some thoughts about SCRAM implementation
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] Some thoughts about SCRAM implementation |
Дата | |
Msg-id | CABUevEw3hn7pJo6Wk7BPP9SdNFKZTpG2_=+p8uTm_92V9u=tXA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Some thoughts about SCRAM implementation (Álvaro Hernández Tortosa <aht@8kdata.com>) |
Ответы |
Re: [HACKERS] Some thoughts about SCRAM implementation
(Álvaro Hernández Tortosa <aht@8kdata.com>)
Re: [HACKERS] Some thoughts about SCRAM implementation (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Apr 11, 2017 at 2:53 PM, Álvaro Hernández Tortosa <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:That can equally be said about about a lot of features. If we don't
On 10/04/17 13:02, Heikki Linnakangas wrote:On 04/10/2017 12:39 PM, Álvaro Hernández Tortosa wrote:Really? That's a real shame.... I know we're very late in the CF cycle- I think channel binding support should be added. SCRAM brings securityWe missed the boat for PostgreSQL 10. You're right that it probably
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.
wouldn't be difficult to implement, but until there's a concrete patch
to discuss, that's a moot point.
but, again, this would be a real shame.
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. 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.
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.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [HACKERS] pgbench --progress-timestamp no longer works correctly
Следующее
От: Álvaro Hernández TortosaДата:
Сообщение: Re: [HACKERS] Some thoughts about SCRAM implementation