Re: Can we stop defaulting to 'md5'?
От | Stephen Frost |
---|---|
Тема | Re: Can we stop defaulting to 'md5'? |
Дата | |
Msg-id | 20200528164404.GA6680@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Can we stop defaulting to 'md5'? (Christoph Berg <myon@debian.org>) |
Ответы |
Re: Can we stop defaulting to 'md5'?
|
Список | pgsql-pkg-yum |
Greetings, * Christoph Berg (myon@debian.org) wrote: > Re: Stephen Frost > > postgresql.conf alone, but ultimately that's probably going to be up to > > what Christoph is comfortable with. > > Re: Stephen Frost > > If you leave it as 'md5' in pg_hba.conf, then *that* will do either md5, > > or scram. If you have 'scram-sha-256' in pg_hba.conf and only an 'md5' > > password then it breaks. > > Fwiw "comfortable" and "it breaks" are the problem here. The whole > picture is so utterly complicated that I'm still scared from reading > the docs the first time around the time PG10 came about. In trainings > I'm still telling people that md5 is the accepted standard because > there's enough more interesting things to teach about PostgreSQL. Ah, well, in trainings and talks I'm pushing to completely get rid of md5 and to only accept using scram. :) > Why do I have to decide *in pg_hba.conf* which hash algorithm is used? Where else would you decide..? > Why can't that just be "password"? What would that mean? > The password_encryption GUC should be the only place concerned with > that, and it should only be used for new passwords. Existing passwords > should just continue to work. *That* would allow seamless upgrades. Sure, that'd be nice, but that isn't how it is today. I argued for similar during the scram implementation but not what ultimately ended up happening. > Getting this mess fixed would be good for security because then people > will likely start using scram. That's certainly true, though I hope we can convince people to use SCRAM even given the modest effort required. The point here though, really, is that *new* installations of PG have very little reason to not use SCRAM. The question on upgrades is different, but that can be addressed with pg_upgradecluster, I would think, without much trouble. Thanks, Stephen
Вложения
В списке pgsql-pkg-yum по дате отправления: