Re: pgAdmin4 4.8 Kubuntu issues

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

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

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

On Thu, Jun 6, 2019, 10:01 richard coleman <rcoleman(dot)ascentgl(at)gmail(dot)com>
wrote:

> Dave,
>
> Thank you for getting back to me.
>
> On Thu, Jun 6, 2019 at 5:01 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Wed, Jun 5, 2019 at 7:29 PM richard coleman <
>> rcoleman(dot)ascentgl(at)gmail(dot)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(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
>>>>>>
>>>>>
>>>>
>>>> --
>>>> 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
>>
>