Re: pgAdmin4 4.8 Kubuntu issues - Mailing list pgadmin-support

All passwords are stored in files of one sort or another.  Hopefully those files are effectively encrypted (assuming of course that you had even had pgAdmin4 save your passwords to begin with).

Now you may have a VPN, but you also may use the same password for different things, or other people might use servers that are less hard to reach.

 The same sort of people who use the same password for a number of things are just going to use that self same password as their master password in pgAdmin4.

How? pgAdmin has no way of doing that over what is essentially a web application - and even if it did, allowing a remotely accessible application (particularly one in which external programs can be configured and executed by users) to modify it's own configuration is a *really* bad idea.

 Well for a start Edge uses Microsoft's user credentials as a master password.  Any number of applications can access files in a protected area and prompt for a sudo/administrator credential. 

As for the choice to make pgAdmin4 a python version of phpPgAdmin, there's been a lot of discussion, most of it not very favorable.  I guess you can chalk this up to one more reason converting pgAdmin from an application to a web app was probably not the best idea.

So basically what we have is a major UI change (users are literally locked out of the application) caused by upgrading a minor version level (4.7 to 4.8) with no simple way to revert the behavior all for a dubious increase in security.

I don't wish to be rude, but it's clear you don't fully appreciate the possible risks here - and I really don't agree that being asked for a password once when the application starts (not an instance of the UI, but the server itself, which may support a number of concurrent or intermittent sessions) is a major UI change. Not that I'd recommend it, but you could have an extremely short password that you type and then press enter. You could even ask your browser to save that password if you're less concerned about security, and then we're talking about *a single mouse click* at the start of your day, or if you're like me, start of your week.

So you don't deny that 4.8 radically changed it's behavior, without warning, from 4.7.  You then seek to minimize the impact this has on people by undermining the reason for implementing it in the first place. Let's see if I am understanding your argument:

• You must force end users to start using a master password because they just don't understand the security risks of not using one.

• In order to force the issue, you lock most of the functionality behind the "Master Password" dialog box until they either scour the internet looking for a way to turn off this feature or submit and enter a master password.

• When someone complains about this heavy handed behavior your solution is to 
  • use an extremely short password
  • have your browser store your password

• point out that you keep pgAdmin4 running for days or weeks at a time, so it's no big deal 

     So, the users must use a master password, because security.  If you find it too burdensome then just use it in a very insecure way.

     How about; 

Don't spring major changes like this on users during a minor update

Make it opt-in not opt-out

Make if very easy for users to turn this feature on or off

Protect the absolute minimum with this feature, not the entire application.

Hardly a major inconvenience.

     And as for your comment about letting pgAdmin run for days/weeks on your machine, congratulations.  When I leave pgAdmin running for more than a couple of hours it becomes unresponsive.  Not the UI, that works just fine, but running any queries will take forever (as in they will literally never finish, just grey out the query tool window). For example SELECT * FROM <table> LIMIT 1;  will never finish, but as soon as I shut down the server (pgAdmin4 not the database server) and restart it will complete instantaneously.  So I need to restart pgAdmin4 the server many times a day. 

I really do hope you'll reconsider this ill-implemented feature.

rik. 

Yes, I think I have been quite restrained in my assessment.

Thanks, 

rik.

On Wed, Jun 5, 2019 at 10:59 AM Dave Page <dpage@pgadmin.org> wrote:

Richard,

On Wed, Jun 5, 2019 at 3:22 PM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Dave, 

And where would that be?  pgAdmin4 the executable and the shared library is located in /usr/bin/.  There are no entries in /etc/ for pgAdmin4.  There is a pgadmin4.db in /home/u/.pgadmin/  but no config files of any kind there either. 

I have no idea, I don't use Ubuntu or any of it's derivatives and don't know where it installs. Have you tried searching for config.py? That is *not* optional, and must exist.

 

So it's looking like the only way to actually use the current version of pgAdmin4 is to create an undocumented file (the help page says you can use config.py as a reference, but guess what?  That file doesn't exist either.) in an unknown location, and manually add the magic string; 

"MASTER_PASSWORD_REQUIRED=False"

I think that's a little hyperbolic don't you? It works as intended, with no changes required if you set the password and re-enter it when you restart pgAdmin. You only need to modify anything if you want to change the behaviour.

And to be clear; if config.py is not present on your system, then there is no way pgAdmin will even start, let alone work.

 

I get why you added this feature, but I think it was implemented completely backwards.  Instead of making every end user jump through these ridiculous hoops just to continue to use pgAdmin4 as they had been up to this point, a better option would be to allow security conscious sys admins to add the configuration:

 "MASTER_PASSWORD_REQUIRED=True"

to a non-user writable configuration file.  In that way the vast majority of people running pgAdmin4 can continue to do so and the few that wanted/needed the added security could do so as well.

That is not how security works. Without the master password feature, there are possible attack vectors in which a stored password could be accessed by third parties. We aim for secure by default; if you don't care about the risk, then you can actively choose to run in a less secure way.

 

So, now I'm using dBeaver as I can't disable the Master Password dialog box and pgAdmin4 won't let me do anything.

Any other thoughts?  Anyone?

Thanks, 

rik.

On Wed, Jun 5, 2019 at 10:03 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, Jun 5, 2019 at 2:44 PM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Dave, 

Sorry, but after an exhaustive search of the several terabytes on my machine, there is no config_local.py file.  Do you have any idea where it's supposed to be located?

You need to create it if it doesn't exist, in the same directory as pgAdmin's config.py.

 

Thanks,

rik.

On Wed, Jun 5, 2019 at 9:30 AM Dave Page <dpage@pgadmin.org> wrote:

On Wed, Jun 5, 2019 at 1:16 PM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Cherio, 

I am sorry to inform you, but there is no mention of "config_local.py" on that page, nor any indication of where I would find it.

https://www.pgadmin.org/docs/pgadmin4/4.x/desktop_deployment.html#configuration

 

rik.

On Tue, Jun 4, 2019 at 5:06 PM Cherio <cherio@gmail.com> wrote:

Put "MASTER_PASSWORD_REQUIRED = False" line into your "lib/python?.?/site-packages/pgadmin4/config_local.py". This is in the docs: https://www.pgadmin.org/docs/pgadmin4/dev/master_password.html

On Tue, Jun 4, 2019 at 4:41 PM richard coleman <rcoleman.ascentgl@gmail.com> wrote:

To whomever, 

Running a newly update pgAdmin 4 version 4.8 on my Kubuntu box.  There are a couple of glaring issues.

First: It keeps prompting to; "Set Master Password"

    I don't want to set another password that I'll just end up forgetting.

Second: When I click the "?" button on that dialog box it takes me to this page:

"http://127.0.0.1:33681/help/help/master_password.html"

Which returns "404 Not Found"

Hopefully there is a simple solution to these issues.

Thanks, 

rik.

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company