Re: pgAdmin4 4.8 Kubuntu issues

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