On Tue, Apr 18, 2017 at 1:52 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 04/14/2017 10:33 PM, Peter Eisentraut wrote: > >> On 4/11/17 01:10, Heikki Linnakangas wrote: >> >>> That question won't arise in practice. Firstly, if the server can do >>> scram-sha-256-plus, it presumably can also do scram-sha-512-plus. Unless >>> there's a change in the way the channel binding works, such that the >>> scram-sha-512-plus variant needs a newer version of OpenSSL or >>> something. Secondly, the user's pg_authid row will contain a >>> SCRAM-SHA-256 or SCRAM-SHA-512 verifier, not both, so that will dictate >>> which one to use. >>> >> >> Right. So putting the actual password method in pg_hba.conf isn't going >> to be useful very often. >> >> I think the most practical thing that the user wants in pg_hba.conf is >> "best password method supported by what is in pg_authid". This is >> currently spelled "md5", which is of course pretty weird. And it will >> become weirder over time. >> >> I think we want to have a new keyword in pg_hba.conf for that, one which >> does not indicate any particular algorithm or method (so not "scram" or >> "sasl"). >> >> We could use "password". If we think that "md5" can mean md5-or-beyond, >> then maybe "password" can mean password-or-md5-or-beyond. >> >> Or otherwise a completely new word. >> >> We also want to give users/admins a way to phase out old methods or set >> some policy. We could either make a global GUC setting >> password_methods='md5 scram-sha-256' and/or make that an option in >> pg_hba.conf past the method field. >> > > Yeah, that would be reasonable. It can't be called just "password", > though, because there's no way to implement "password-or-md5-or-scram" in a > sensible way (see my reply to Simon at [1]). Unless we remove the support > for what "password" does today altogether, and redefine "password" to mean > just "md5-or-beyond". Which might not be a bad idea, but that's a separate > discussion. > It is an interesting one though. "password" today is really only useful in the case of db_user_namespace=on, right? Given the very few people I think are using that feature, it wouldn't be unreasonable to rename it to something more closely related to that. However, that would also leave us in the position to explain "before 10, avoid using password because it stores in clear text. after 10, we recommend you use password". Reusing something that's existed before and not really been secure for something that would be a good choice in the future seems like a bad idea. But we can also implement this functionality but under a differet name. Like just "hashed" or something, which would mean md5-or-scram? > In any case, I think we would probably still need more fine-grained > control, too, so we would still need to have "scram-sha-256" as a method > you can specify directly in pg_hba.conf. So I consider this as a separate, > new, feature that we can add in the future, if it seems worth the effort. > Yes, I think wherever we go we don't want to loose the fine-grained control. But some people will be happier for not having to use it. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
