Обсуждение: Defaulting to password_encryption = scram-sha-256

Hi,

Now that we probably have shaken the worst issues out of scram,
shouldn't we change the default password_encryption to something that
doesn't scare people?   The only reason I could think of not wanting to
do that for is that we don't necessarily guarantee that we have a strong
random generator, but if that's the issue, we should change initdb to
default it to something safe if the platform provides something. Which
is just about any sane one, no?

Greetings,

Andres Freund

On Sat, Oct 06, 2018 at 11:43:06PM -0700, Andres Freund wrote:
> Now that we probably have shaken the worst issues out of scram,
> shouldn't we change the default password_encryption to something that
> doesn't scare people?   The only reason I could think of not wanting to
> do that for is that we don't necessarily guarantee that we have a strong
> random generator, but if that's the issue, we should change initdb to
> default it to something safe if the platform provides something. Which
> is just about any sane one, no?

In short, +1.

The random function issue would apply to any platform in need of
--disable-strong-random, but this applies mainly to some old HP-UX stuff
if my memory serves me well, so I'd like to think that we should be safe
to just switch the default and not complicate initdb.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Oct 06, 2018 at 11:43:06PM -0700, Andres Freund wrote:
>> Now that we probably have shaken the worst issues out of scram,
>> shouldn't we change the default password_encryption to something that
>> doesn't scare people?   The only reason I could think of not wanting to
>> do that for is that we don't necessarily guarantee that we have a strong
>> random generator, but if that's the issue, we should change initdb to
>> default it to something safe if the platform provides something. Which
>> is just about any sane one, no?

> In short, +1.

> The random function issue would apply to any platform in need of
> --disable-strong-random, but this applies mainly to some old HP-UX stuff
> if my memory serves me well, so I'd like to think that we should be safe
> to just switch the default and not complicate initdb.

Yeah, I don't see why that should affect anything.  SCRAM with a poor
random function is probably still better than MD5.

As I recall, the reason for not defaulting to SCRAM right away had
nothing to do with that; it was worry about how many clients would
get locked out for lack of SCRAM support.  But the list at
https://wiki.postgresql.org/wiki/List_of_drivers
looks pretty positive, and another year would probably be enough
to give the stragglers time to catch up ... especially if they know
this is coming.

            regards, tom lane

Hi,

On 2018-10-07 11:37:20 -0400, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > On Sat, Oct 06, 2018 at 11:43:06PM -0700, Andres Freund wrote:
> >> Now that we probably have shaken the worst issues out of scram,
> >> shouldn't we change the default password_encryption to something that
> >> doesn't scare people?   The only reason I could think of not wanting to
> >> do that for is that we don't necessarily guarantee that we have a strong
> >> random generator, but if that's the issue, we should change initdb to
> >> default it to something safe if the platform provides something. Which
> >> is just about any sane one, no?
> 
> > In short, +1.
> 
> > The random function issue would apply to any platform in need of
> > --disable-strong-random, but this applies mainly to some old HP-UX stuff
> > if my memory serves me well, so I'd like to think that we should be safe
> > to just switch the default and not complicate initdb.
> 
> Yeah, I don't see why that should affect anything.  SCRAM with a poor
> random function is probably still better than MD5.

Cool.


> As I recall, the reason for not defaulting to SCRAM right away had
> nothing to do with that; it was worry about how many clients would
> get locked out for lack of SCRAM support.

Right, but two releases should be enough of a warning window.


> But the list at https://wiki.postgresql.org/wiki/List_of_drivers looks
> pretty positive, and another year would probably be enough to give the
> stragglers time to catch up ... especially if they know this is
> coming.

I've updated the list, and I think it looks a bit better now. Go/pq and
Node/node-postgres seem to be the only somewhat important ones without
support. The former has had open PRs for it for quite a while.

Greetings,

Andres Freund