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.ascen...@gmail.com> wrote: > Michel, > > Thanks for jumping into the conversation. > > On Wed, Jun 5, 2019 at 12:18 PM Michel Feinstein < > michelfeinst...@gmail.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.ascen...@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 <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 >>>> >>>>
