Re: Successor of MD5 authentication, let's use SCRAM

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Darren Duncan <darren(at)darrenduncan(dot)net>, John R Pierce <pierce(at)hogranch(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Successor of MD5 authentication, let's use SCRAM
Date: 2012-10-14 21:17:46
Message-ID: CAAZKuFb1QsMoaDHr2__78tmaqXgR8akng6gJLy8iqPDi-CQxiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 14, 2012 at 2:04 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> There's a lot of shades of gray to that one. Way too many to say
> they're right *or* wrong, IMHO.

We can agree it is 'sub-ideal', but there is not one doubt in my mind
that it is not 'right' given the scope of Debian's task, which does
*not* include pushing applied cryptography beyond its current pitiful
state.

Debian not making self-signed certs available by default will just
result in a huge amount of plaintext database authentication and
traffic available over the internet, especially when you consider the
sslmode=prefer default, and as a result eliminate protection from the
most common class of attack for users with low-value (or just
low-vigilance) use cases. In aggregate, that is important, because
there are a lot of them.

It would be a net disaster for security.

> It *does* make people think they have "full ssl security by default",
> which they *don't*.They do have partial protection, which helps in
> some (fairly common) scenarios. But if you compare it to the
> requirements that people *do* have when they use SSL, it usually
> *doesn't* protect them the whole way - but they get the illusion that
> it does. Sure, they'd have to read up on the details in order to get
> secure whether it's on by default or not - that's why I think it's
> hard to call it either right or wrong, but it's rather somewhere in
> between.

If there is such blame to go around, I place such blame squarely on
clients. More secure is the JDBC library, which makes you opt into
logging into a server that has no verified identity via configuration.
The problem there is that it's a pain to get signed certs in, say, a
test environment, so "don't check certs" will make its way into the
default configuration, and now you have all pain and no gain.

--
fdr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-10-14 21:29:31 Re: Deprecating RULES
Previous Message Brar Piening 2012-10-14 21:13:46 Re: Visual Studio 2012 RC