*(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.ascen...@gmail.com> wrote: > Dave, > > Thank you for getting back to me. > > On Thu, Jun 6, 2019 at 5:01 AM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Wed, Jun 5, 2019 at 7:29 PM richard coleman < >> rcoleman.ascen...@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 <dp...@pgadmin.org> wrote: >>>>> >>>>>> Richard, >>>>>> >>>>>> On Wed, Jun 5, 2019 at 3:22 PM richard coleman < >>>>>> rcoleman.ascen...@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 <dp...@pgadmin.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 5, 2019 at 2:44 PM richard coleman < >>>>>>>> rcoleman.ascen...@gmail.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 <dp...@pgadmin.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jun 5, 2019 at 1:16 PM richard coleman < >>>>>>>>>> rcoleman.ascen...@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 <che...@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.ascen...@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 >> >
