Обсуждение: pgAdmin4 4.8 Kubuntu issues

It would be easier if the system when prompting for the Master Password, had a "I don't want to define a Master Password" or something like that, which would set that config_local.py property automatically. 

On Tue, Jun 4, 2019, 18:06 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.

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"

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.

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.

It’s not just on Kubuntu – it also occurs on Windows as well.

 

There should be a user-friendly way to turn that off.

 

pgAdmin III seems a lot better for functionality and usability.

 

 

From: richard coleman <rcoleman.ascentgl@gmail.com>
Sent: Wednesday, June 05, 2019 8:17 AM
To: Cherio <cherio@gmail.com>
Cc: pgAdmin Support <pgadmin-support@postgresql.org>
Subject: [EXTERNAL] - Re: pgAdmin4 4.8 Kubuntu issues

 

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.

 

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, 

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?

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, 

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. 

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 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.

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, 

Actually I thought I was being quite restrained in my assessment.  With version 4.8 the developers completely upended the end user experience.  From pgAdmin3 through all versions of pgAdmin4 prior to the current one, the end user could start pgAdmin and then get to work creating connections, modifying databases, running queries as their postgreSQL permissions allowed.  If they wanted to save a password, that was their choice (though it didn't always work).  Suddenly with pgAdmin4 4.8 they are locked out of the application by a required Master Password.  To make matters worse, there is no simple or even well defined way to disable this change.  The solution is to dig through the documentation, then rummage around on your file system (as the exact location varies by OS or distribution) for a sample file (the config file isn't actually documented in the official documentation).  Then create a brand new file, make sure you include the magic setting, restart pgAdmin4 and you will finally get back to working the way you did before you let pgAdmin4 update itself from 4.7 to 4.8.

The only situation I can envision (and perhaps I'm just not paranoid enough) is if someone breaks into my computer, gets my login credentials, gets the separate login credentials to the VPN I use to connect to the corporate network, and then manages to start pgAdmin4 as myself to connect to a postgreSQL database, that I've just happened to have had pgAdmin4 save the password to and commit some sort of mischief with my level of access.

So, to summarize an attacker would have had to:

1. hack my machine
2. hack into the corporate network through my VPN credentials (which they would have to hack)
3. run pgAdmin4 as me
4. have relied on me having pgAdmin4 save my passwords.

The only thing I gain from the new Master Password requirement is that if I had pgAdmin4 save my passwords, an attacker would have need to know one more password to unlock pgAdmin4.

Unfortunately if I don't have pgAdmin4 save my passwords, I still have to remember a Master Password.  Why?  Without step 4 above, it doesn't actually provide anymore security.

To add insult to injury I (like many people currently using pgAdmin4) have root access (or Administrator level credentials for those Windows users) to my own machine.  Which means it's possible for me to jump through all of the hoops to disable the Master Password mechanism.  So what did not having a setting in the Preferences UI gain in terms of security?  If you wanted to restrict changing that setting to users with the required level of access you could have simply gated it with a sudo/administrator credentials dialog. 

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.

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

Let me just add some points to the discussion:

1 - Your use case is different than most people, you have a VPN in the middle of your workflow. Besides, you are imaging someone breaking into your computer, but the attack vector is much simpler than that. 

Someone can craft a malware that will automatically scan for pgAdmin passwords, upon arriving on any machine, and send whatever it's found to his creator. This could spread all over the internet, and one of your employees with less security awareness could click the wrong email attachment and then leak his database credentials. Google employees have been victim to physhing attacks (that's why they use smart cards now), I can't imagine this won't happen somewhere else.

Many companies don't have their databases behind a VPN, specially in cloud environments (some use a VPC, some don't for many reasons, not related to this topic).

Besides, I could be wrong, but I think a malware on your computer could read your pgAdmin passwords, then submit queries to your company's database from inside your own computer, since it's already connected to your VPN, and then send back to the attacker the results, so it won't have to steal any VPN credentials, just use your own connection as a bridge. It doesn't have to target you specifically, just send a ping back whenever it detects pgAdmin passwords in a machine and then go to "Bridge mode". I might be wrong since I almost never use a VPN and am not used to its inner workings. 

2 - I think the opt-out should be more streamlined, the security risks should be better informed and the Master Password should only be asked if the user decided to save a password in the first place.

3 - pgAdmin could create an empty configuration file by default, so it would be easier to locate it in all Linux distributions.

Those are my 2 cents. 

On Wed, Jun 5, 2019, 12:55 richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Dave, 

Actually I thought I was being quite restrained in my assessment.  With version 4.8 the developers completely upended the end user experience.  From pgAdmin3 through all versions of pgAdmin4 prior to the current one, the end user could start pgAdmin and then get to work creating connections, modifying databases, running queries as their postgreSQL permissions allowed.  If they wanted to save a password, that was their choice (though it didn't always work).  Suddenly with pgAdmin4 4.8 they are locked out of the application by a required Master Password.  To make matters worse, there is no simple or even well defined way to disable this change.  The solution is to dig through the documentation, then rummage around on your file system (as the exact location varies by OS or distribution) for a sample file (the config file isn't actually documented in the official documentation).  Then create a brand new file, make sure you include the magic setting, restart pgAdmin4 and you will finally get back to working the way you did before you let pgAdmin4 update itself from 4.7 to 4.8.

The only situation I can envision (and perhaps I'm just not paranoid enough) is if someone breaks into my computer, gets my login credentials, gets the separate login credentials to the VPN I use to connect to the corporate network, and then manages to start pgAdmin4 as myself to connect to a postgreSQL database, that I've just happened to have had pgAdmin4 save the password to and commit some sort of mischief with my level of access.

So, to summarize an attacker would have had to:

1. hack my machine
2. hack into the corporate network through my VPN credentials (which they would have to hack)
3. run pgAdmin4 as me
4. have relied on me having pgAdmin4 save my passwords.

The only thing I gain from the new Master Password requirement is that if I had pgAdmin4 save my passwords, an attacker would have need to know one more password to unlock pgAdmin4.

Unfortunately if I don't have pgAdmin4 save my passwords, I still have to remember a Master Password.  Why?  Without step 4 above, it doesn't actually provide anymore security.

To add insult to injury I (like many people currently using pgAdmin4) have root access (or Administrator level credentials for those Windows users) to my own machine.  Which means it's possible for me to jump through all of the hoops to disable the Master Password mechanism.  So what did not having a setting in the Preferences UI gain in terms of security?  If you wanted to restrict changing that setting to users with the required level of access you could have simply gated it with a sudo/administrator credentials dialog. 

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.

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

Richard,

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

Dave, 

Actually I thought I was being quite restrained in my assessment.  With version 4.8 the developers completely upended the end user experience.  From pgAdmin3 through all versions of pgAdmin4 prior to the current one, the end user could start pgAdmin and then get to work creating connections, modifying databases, running queries as their postgreSQL permissions allowed.  If they wanted to save a password, that was their choice (though it didn't always work).  Suddenly with pgAdmin4 4.8 they are locked out of the application by a required Master Password.  To make matters worse, there is no simple or even well defined way to disable this change.  The solution is to dig through the documentation, then rummage around on your file system (as the exact location varies by OS or distribution) for a sample file (the config file isn't actually documented in the official documentation).  Then create a brand new file, make sure you include the magic setting, restart pgAdmin4 and you will finally get back to working the way you did before you let pgAdmin4 update itself from 4.7 to 4.8.

I've committed changes to improve the documentation.

 

The only situation I can envision (and perhaps I'm just not paranoid enough) is if someone breaks into my computer, gets my login credentials, gets the separate login credentials to the VPN I use to connect to the corporate network, and then manages to start pgAdmin4 as myself to connect to a postgreSQL database, that I've just happened to have had pgAdmin4 save the password to and commit some sort of mischief with my level of access.

So, to summarize an attacker would have had to:

1. hack my machine
2. hack into the corporate network through my VPN credentials (which they would have to hack)
3. run pgAdmin4 as me
4. have relied on me having pgAdmin4 save my passwords.

Nope. Way easier than that. A flaw in a browser plugin or browser, or effective social engineering, or a malicious application can leak files on your system, and as stored passwords are stored in, well, files.

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.

The only thing I gain from the new Master Password requirement is that if I had pgAdmin4 save my passwords, an attacker would have need to know one more password to unlock pgAdmin4.

Unfortunately if I don't have pgAdmin4 save my passwords, I still have to remember a Master Password.  Why?  Without step 4 above, it doesn't actually provide anymore security.

To add insult to injury I (like many people currently using pgAdmin4) have root access (or Administrator level credentials for those Windows users) to my own machine.  Which means it's possible for me to jump through all of the hoops to disable the Master Password mechanism.  So what did not having a setting in the Preferences UI gain in terms of security?  If you wanted to restrict changing that setting to users with the required level of access you could have simply gated it with a sudo/administrator credentials dialog. 

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:

Hardly a major inconvenience.

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

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

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

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).

Sure, in pgAdmin 4 they are (unlike pgAdmin 3 which used PostgreSQL's .pgpass files which are plain text). However, the problem is that unless the key to encrypt/decrypt those passwords is stored externally (e.g. in the users brain, or on a Ubikey or similar), it is also in a file.

Then it becomes one more thing for users to forget/write down/reuse something they already know.

 

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.

Sure - however, I'm not ever going to make the default security in pgAdmin cater to people who do stupid things like that, or just assume that people are already doing stupid things so we shouldn't bother. We will always strive to be secure by default, within the bounds of reasonable user experience.

The only thing you might be securing are saved passwords, if the user has saved any.  By locking up the entire application behind the master password, you are just encouraging bad behavior for little to no gain.  

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. 

We could do that too. Assuming users were happy to setup a Kerberos infrastructure. Otherwise, we'd need to rely on browser password saving which isn't always reliable. The browser intentionally doesn't allow us to access locally held credentials as that would be massively insecure.

 

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.

Funny that, whilst there certainly have been people who didn't like the change, the *vast* majority of feedback I receive has been positive since we ironed out the very early performance issues. Downloads are up massively as well, and that's before you count the Docker distro that didn't exist with pgAdmin 3, which has been over 5M pulls for quite some time now (I don't know the banding of Dockers numbers - I assume it'll go to 10M+ at some point). 

Are you really basing popularity on a comparison to pgAdmin3, the same version that isn't supported, and has one Windows only fork that supports postgreSQL 10?  If people want a gui to administer postgreSQL 11+, the most promoted one is pgAdmin4.  If pgAdmin3 supported postgreSQL 11+ most people would still be using it.

Regardless, I'm happy with the change, and I'm happy in the knowledge that most users seem to agree. Those that don't are welcome to use the LTS version of pgAdmin 3 if they prefer, or other tools. It's a free world (for the most part) - people can and should use what they find most productive and useful for them. I will carry on working on and providing (for free) the tools that interest me.

Just go back through the emails on this list alone and read the many emails of people writing; pgAdmin3 did this, why doesn't pgAdmin4?  They are not even talking about new features, just simple feature parity. The most recent one that comes to mind is the decision to hide the explain results behind a "[". 

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're obviously not. I don't deny there is a minor change in workflow, which can be trivially disabled (hopefully more since now I've improved the docs based on your feedback). 

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

Nope. I said (intended respectfully), that I didn't believe you understood the attack vectors we were discussing. That is absolutely *not* the same as saying "users" don't understand in general. 

• 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.

As noted twice now, I've updated the documentation based on your feedback. 

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

Nope again. I specifically said that I didn't recommend doing that, I was just pointing out that you could if you chose to.

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

Sure. Even if I were restarting a couple of times a day, I don't believe entering a password each time is a major inconvenience. It would be such an insanely miniscule amount of typing/clicking compared to everything else I do in a day that I couldn't begin to count it.

I guess that would depend on the number of passwords you have to remember.

Think about it; I've probably spent an hour or so in total on this discussion so far. Even if I took 5 seconds to enter the password (It's probably way less than that), that's 720 times I could have entered that password.

 Assuming you could remember it.  Most people end up reusing the same password, not because they are stupid, but because they have way too many to remember already.

     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

A major update for pgAdmin is one that radically changes the entire application design or architecture. Minor updates constantly add both small and large features.

I think most people would agree that locking users out of the entire application on a minor upgrade is a major change. 

Make it opt-in not opt-out

Not going to happen.

Why? Is it because, given the choice, most users don't have the high security need that would make having to remember another password worth the effort. 

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

Docs have been improved, but it's not going to become a preference for reasons already discussed (at least not without a complete overhaul of the preferences system to allow admins to lock users out of certain changes).

You wouldn't have to if it was opt-in. Administrators would have the technical know-how, and the appropriate permissions to modify config files manually, should they feel the need for that level of security.  

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

It could be improved to only prompt for the password the first time a user tries to connect to a server with a saved password. I suspect that would only make a difference for a very small number of people though, as most will either save all or none of their passwords (and the latter group might have password saving disabled in the application config anyway).

It should only prompt for a password when the user is connecting using a saved connection that has a saved password.  If the user wants to create another connection, or use one that doesn't have a saved password, it shouldn't matter. 

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. 

Have you logged an issue about that with logs etc? If that is what happens for you, then I'd certainly like to resolve that.

 

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

I've already reconsidered it - I always reconsider things when we get user feedback. In this case though, I don't agree with your arguments. The extra security adds a trivial overhead to user workflow, and those that don't want it can disable it completely with a couple of minutes of effort, all whilst allowing sysadmins to enforce the use of the feature if they want.

For most people the extra security isn't worth the effort.  As implemented it provides a modest to non existent increase in security while inconveniencing users and encouraging poor security hygiene.  The only reason most people will grudgingly submit is because there is no easy way to turn it off (and no, adding magic strings to user created files in random locations is not easy, no matter how good the documentation is).  They'll just reuse a password they already use, or hit <space> or 'a' as their password.

I've said my piece on the topic now - on to other subjects.

 

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

--

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

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

(if the malicious actor can steal the file they can also read the key from memory)

As far as I know it's a lot easier for a program to get access to all the files in a system (specially on Windows) than to dump the memory, as there are memory barriers protected by the OS (and address randomization) that limits the addresses a program has access. 

That would depend on your expected adversary, and the OS you are running on.

Sure there are read/write controls for files as well, but not as restrictive as memory barriers. 

This also depends on the OS you are running on, and how your machine's been configured.

PS: Sorry for not using the fancy colors and reply marks, I am on my phone. 

rik.

On Thu, Jun 6, 2019, 10:01 richard coleman <rcoleman.ascentgl@gmail.com> wrote:

Dave, 

Thank you for getting back to me.

On Thu, Jun 6, 2019 at 5:01 AM Dave Page <dpage@pgadmin.org> wrote:

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

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).

Sure, in pgAdmin 4 they are (unlike pgAdmin 3 which used PostgreSQL's .pgpass files which are plain text). However, the problem is that unless the key to encrypt/decrypt those passwords is stored externally (e.g. in the users brain, or on a Ubikey or similar), it is also in a file.

Then it becomes one more thing for users to forget/write down/reuse something they already know.

 

 

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.

Sure - however, I'm not ever going to make the default security in pgAdmin cater to people who do stupid things like that, or just assume that people are already doing stupid things so we shouldn't bother. We will always strive to be secure by default, within the bounds of reasonable user experience.

The only thing you might be securing are saved passwords, if the user has saved any.  By locking up the entire application behind the master password, you are just encouraging bad behavior for little to no gain.  

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. 

We could do that too. Assuming users were happy to setup a Kerberos infrastructure. Otherwise, we'd need to rely on browser password saving which isn't always reliable. The browser intentionally doesn't allow us to access locally held credentials as that would be massively insecure.

 

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.

Funny that, whilst there certainly have been people who didn't like the change, the *vast* majority of feedback I receive has been positive since we ironed out the very early performance issues. Downloads are up massively as well, and that's before you count the Docker distro that didn't exist with pgAdmin 3, which has been over 5M pulls for quite some time now (I don't know the banding of Dockers numbers - I assume it'll go to 10M+ at some point). 

Are you really basing popularity on a comparison to pgAdmin3, the same version that isn't supported, and has one Windows only fork that supports postgreSQL 10?  If people want a gui to administer postgreSQL 11+, the most promoted one is pgAdmin4.  If pgAdmin3 supported postgreSQL 11+ most people would still be using it.

Regardless, I'm happy with the change, and I'm happy in the knowledge that most users seem to agree. Those that don't are welcome to use the LTS version of pgAdmin 3 if they prefer, or other tools. It's a free world (for the most part) - people can and should use what they find most productive and useful for them. I will carry on working on and providing (for free) the tools that interest me.

Just go back through the emails on this list alone and read the many emails of people writing; pgAdmin3 did this, why doesn't pgAdmin4?  They are not even talking about new features, just simple feature parity. The most recent one that comes to mind is the decision to hide the explain results behind a "[". 

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're obviously not. I don't deny there is a minor change in workflow, which can be trivially disabled (hopefully more since now I've improved the docs based on your feedback). 

Trivially disabled would have been a Preference Option, or a button on the "Master Password" dialog that lets the user choose "I don't want to use one". 

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

Nope. I said (intended respectfully), that I didn't believe you understood the attack vectors we were discussing. That is absolutely *not* the same as saying "users" don't understand in general. 

I understand the attack vector just fine.  You don't think the the default encryption pgAdmin4 uses to store saved passwords is sufficient should some malicious actor manage to steal that file.  I just don't believe that your proposed solution provides that much more security (if the malicious actor can steal the file they can also read the key from memory).  If you truly wanted a secure solution, you would prompt the end user for the master password for every connection that has a saved password, when it was connecting.  That way you would be minimizing the time the master key was in memory.  The only benefit to the end user would be they could remember one master password instead of many (presumably very convoluted) individual passwords. 

• 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.

As noted twice now, I've updated the documentation based on your feedback. 

Improved documentation is always appreciated.  What you haven't said is that you'll free up the majority of the functionality that doesn't rely on a "Master Password", from that dialog. 

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

Nope again. I specifically said that I didn't recommend doing that, I was just pointing out that you could if you chose to.

Which defeats the entire reason behind this change. 

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

Sure. Even if I were restarting a couple of times a day, I don't believe entering a password each time is a major inconvenience. It would be such an insanely miniscule amount of typing/clicking compared to everything else I do in a day that I couldn't begin to count it.

I guess that would depend on the number of passwords you have to remember.

Think about it; I've probably spent an hour or so in total on this discussion so far. Even if I took 5 seconds to enter the password (It's probably way less than that), that's 720 times I could have entered that password.

 Assuming you could remember it.  Most people end up reusing the same password, not because they are stupid, but because they have way too many to remember already.

     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

A major update for pgAdmin is one that radically changes the entire application design or architecture. Minor updates constantly add both small and large features.

I think most people would agree that locking users out of the entire application on a minor upgrade is a major change. 

Make it opt-in not opt-out

Not going to happen.

Why? Is it because, given the choice, most users don't have the high security need that would make having to remember another password worth the effort. 

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

Docs have been improved, but it's not going to become a preference for reasons already discussed (at least not without a complete overhaul of the preferences system to allow admins to lock users out of certain changes).

You wouldn't have to if it was opt-in. Administrators would have the technical know-how, and the appropriate permissions to modify config files manually, should they feel the need for that level of security.  

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

It could be improved to only prompt for the password the first time a user tries to connect to a server with a saved password. I suspect that would only make a difference for a very small number of people though, as most will either save all or none of their passwords (and the latter group might have password saving disabled in the application config anyway).

It should only prompt for a password when the user is connecting using a saved connection that has a saved password.  If the user wants to create another connection, or use one that doesn't have a saved password, it shouldn't matter. 

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. 

Have you logged an issue about that with logs etc? If that is what happens for you, then I'd certainly like to resolve that.

 

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

I've already reconsidered it - I always reconsider things when we get user feedback. In this case though, I don't agree with your arguments. The extra security adds a trivial overhead to user workflow, and those that don't want it can disable it completely with a couple of minutes of effort, all whilst allowing sysadmins to enforce the use of the feature if they want.

For most people the extra security isn't worth the effort.  As implemented it provides a modest to non existent increase in security while inconveniencing users and encouraging poor security hygiene.  The only reason most people will grudgingly submit is because there is no easy way to turn it off (and no, adding magic strings to user created files in random locations is not easy, no matter how good the documentation is).  They'll just reuse a password they already use, or hit <space> or 'a' as their password.

I've said my piece on the topic now - on to other subjects.

I hope that they are handled better than this 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

--

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

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