On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
* Dave Page (dpage@pgadmin.org) wrote: > On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander <magnus@hagander.net> wrote: > > One question around that though -- when I click "save password" on a > > database connection in pgadmin, it gets stored on the pgadmin server. > > Isn't the key used to encrypt that derived from my password? If I'm > > logging into pgadmin without a password (using kerberos),what would > > that key be derived from? > > Also correct - and right now, the plan is to disable password saving if > logged in using Kerberos.
Disable password *saving*, or disable password *using*?
I'm pretty sure I wrote "saving".
If you're saying that, when Kerberos is enabled, users will never be prompted to provide a password because password-based auth has been disabled, then perhaps that's reasonable. I don't know how useful such a pgadmin setup would be, but at least it wouldn't be violating one of the core values that using Kerberos brings.
If you're saying that this is just disabling password *saving*, then that implies that if someone actually wants to use pgadmin to, uh, log into a PostgreSQL server which is configured for md5 or SCRAM auth or LDAP based auth that the way that'll work is that pgadmin will prompt the user for a password, which the user will provide and which will then be sent from the client to the pgadmin system in the clear, and which pgadmin will turn around and use to log into PG with, right?
Yes.
It's the latter than I'm concerned with because it just wouldn't be appropriate for a Kerberized service which is set up to use Kerberos to then prompt the user for a password.
Well you never answered my previous question about that. Why is it appropriate for an FDW to do that, but not pgAdmin? Or for a user on a kerberised machine to use a web browser to access a non-kerberised site? Or frankly pretty much anything outside of a windows domain or kerberos environment that a user inside the environment might want to use?
You basically seem to be saying that once a user logs into something using Kerberos, *everything* else they login to from there must also be done using Kerberos - which clearly will not be the case in the vast majority of deployments.