Re: pgAdmin4 4.8 Kubuntu issues

Michel,

I appreciate your taking the time to weigh in on this. As I mentioned
previously, I can understand why this feature was added, other applications
have a "*master password to protect other saved passwords*"
feature. Chrome *used to* before they went to protecting it with your
Google account. Firefox (FF) still does. The problem as I see it was in
the implementation. In FF it's opt-in, and basically transparent to the
user. Unless you want to *view* the saved passwords in plain text, none of
the features are effected. Contrast that with how pgAdmin4 has chosen to
implement it. It's a *painful* opt-out and it locks nearly everything
except the preferences regardless of whether or not you've had pgAdmin4
save *any* passwords at all. Basically the developers have decided that
you are going to use this new *Master Password* mechanism or you are not
going to have access to the program or any of the server connections you've
already created. One day you are going along using pgAdmin4, then there's
an update. You update pgAdmin4 and *Bam!* You *must* enter a master
password, or else. Now you are posting on lists like this one, or scouring
the internet looking for some way to turn this stupid thing off. Or you're
just going to enter something like "a" as your password (or "password", or
the exact same password you use to login/email/and everything else).

I feel it was *badly* handled. No warning, painful opt-out, locks *way too
much* functionality.

I really do hope the devs reconsider this poor decision.

rik.

On Wed, Jun 5, 2019 at 1:27 PM Michel Feinstein <michelfeinstein(at)gmail(dot)com>
wrote:

> Hi Richard,
>
> I am jumping-in specially because I am the guy to blame for this new
> feature. I identified the security risks and reported it, so I understand
> your frustration and feel bad that your work flow is not as comfortable as
> it was before. I hate when this happens to me.
>
> I also think that using the OS method for storing secrets would be more
> desirable, but I also understand this is way harder to achieve, since there
> would be Windows, Linux and Mac specific code into the project, which is
> way harder to develop than a simple Master Password.
>
> In my particular case, I have some very big alphanumeric passwords for my
> database users and a more user-friendly Master Password on my machine.
> Having to remember the database passwords is a pain, so I store them
> encrypted, so having a simpler Master Password is a very convenient
> solution for my use case, as I don't trust any passwords to be stored
> without encryption.
>
> I am not a developer into the pgAdmin project, I am just pointing out how
> this feature can be good and help some people, while improving security.
>
> I would argue that this discussion on opt-in VS opt-out should be
> investigated according to user impact. If lots of people complain, than
> this should be changed, if they don't, then keep it, as it's more secure. I
> know it's not going to help in your case, but seems more balanced to me on
> security vs. Usage, on a more democratic way.
>
> And again, I think the docs should explain this at length.
>
> Sorry if my input wasn't very helpful on your use case.
>
> Michel.
>
> On Wed, Jun 5, 2019, 14:03 richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>
> wrote:
>
>> Michel,
>>
>> Thanks for jumping into the conversation.
>>
>> On Wed, Jun 5, 2019 at 12:18 PM Michel Feinstein <
>> michelfeinstein(at)gmail(dot)com> wrote:
>>
>>> 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.
>>>
>>> Yep, that *could* happen. But the proposed solution is to add yet
>> *another* password? If the developers were *truly *trying to increase
>> the security of pgAdmin4 from this attack vector, the simplest solution
>> would be to *remove* the ability of pgAdmin4 to save passwords. Many of
>> our machines use ip or other non-password based security to control access
>> to our databases. pgAdmin could force some other non-password security if
>> the user wanted to save their credentials. Or pgAdmin could save their
>> credentials protected by the same mechanism the OS saves user
>> credentials.
>>
>> 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.
>>>
>>> Which just goes back to my earlier point of; 'if that's what you are
>> worried about, then don't let users save passwords'.
>>
>>> 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.
>>>
>>
>> I think it should be an *opt-in*. That's how most other applications
>> that utilize a master password work.
>>
>>>
>>> 3 - pgAdmin could create an empty configuration file by default, so it
>>> would be easier to locate it in all Linux distributions.
>>>
>>> It shouldn't need one, the user should be able to use or not use a
>> master password from the Preferences UI. If they want to use one, fine.
>> If not, that's OK too. If they were and want to stop, warn the user and
>> wipe all of the existing passwords.
>>
>>> Those are my 2 cents.
>>>
>>> Thanks again,
>>
>> rik.
>>
>>> On Wed, Jun 5, 2019, 12:55 richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)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(at)pgadmin(dot)org> wrote:
>>>>
>>>>> Richard,
>>>>>
>>>>> On Wed, Jun 5, 2019 at 3:22 PM richard coleman <
>>>>> rcoleman(dot)ascentgl(at)gmail(dot)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(at)pgadmin(dot)org> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 5, 2019 at 2:44 PM richard coleman <
>>>>>>> rcoleman(dot)ascentgl(at)gmail(dot)com> wrote:
>>>>>>>
>>>>>>>> Dave,
>>>>>>>>
>>>>>>>> Sorry, but after an e*xhaustive* 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(at)pgadmin(dot)org> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jun 5, 2019 at 1:16 PM richard coleman <
>>>>>>>>> rcoleman(dot)ascentgl(at)gmail(dot)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(at)gmail(dot)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(dot)ascentgl(at)gmail(dot)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
>>>>>
>>>>>