On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost <sfr...@snowman.net> wrote:
> Greetings, > > * Dave Page (dp...@pgadmin.org) wrote: > > On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander <mag...@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. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com
