On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal < aditya.toshni...@enterprisedb.com> wrote:
> > > On Fri, Apr 22, 2022 at 3:28 PM Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >> aditya.toshni...@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> Generally, secure keys like API_KEYS and all are supposed to be set in >>> env and are read by the app. Similar is the alternative encryption key. >>> People can run their scripts to export those config vars. >>> >> >> On the client side, yes. This is server side though. It's not uncommon on >> the server side to include hooks to allow key retrieval from external key >> management systems. >> > Even on the server side. Like the AWS auth keys, or DB passwords. We can > include hooks, not against it. Just discussing. > If you're using an AWS auth key on a server, then you're acting as a client for AWS - and DB passwords are a great example of why using a hook is a good thing; it's a very common request from users to have a secure way to retrieve credentials from an external service. Not to mention that a DB password is needed on the client side of a connection, not on the server side. On the server side, the database would query LDAP/Kerberos/whatever. A better example would be querying a key management service to unlock an encrypted disk or something like the service Bruce wrote for managing pgcrypto keys. > >> >> >>> >>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>> khushboo.va...@enterprisedb.com> wrote: >>> >>>> >>>> >>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <dp...@pgadmin.org> wrote: >>>> >>>>> >>>>> >>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>> khushboo.va...@enterprisedb.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <dp...@pgadmin.org> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>> akshay.jo...@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Thanks, the patch applied. >>>>>>>> >>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>> khushboo.va...@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please find the attached patch to implement the feature #7012 - >>>>>>>>> Disable master password requirement when using alternative auth source >>>>>>>>> >>>>>>>>> When pgAdmin stores a connection password, it encrypts it using a >>>>>>>>> key that is formed either from the master password, or from the >>>>>>>>> pgAdmin >>>>>>>>> login password for the user. In the case of auth methods such as >>>>>>>>> OAuth, >>>>>>>>> Kerberos or Webserver, pgAdmin doesn't have access to anything >>>>>>>>> long-lived >>>>>>>>> to form the encryption key from, hence it uses the master password. >>>>>>>>> And if >>>>>>>>> the master is disabled, there is no way to store the connection >>>>>>>>> password. >>>>>>>>> >>>>>>>>> To resolve this, we have added an option to config.py (which >>>>>>>>> defaults to None) for an alternate encryption key. pgAdmin would use >>>>>>>>> this >>>>>>>>> if a) the master password is disabled AND b) there is no suitable >>>>>>>>> key/password available from the auth module for the user. If the >>>>>>>>> option is set to None, pgAdmin works as it does now. >>>>>>>>> >>>>>>>> >>>>>>> This change has just been brought to my attention through other >>>>>>> work. I think this is poorly thought out, and could easily be made much >>>>>>> more secure and flexible than the current design. >>>>>>> >>>>>>> Instead of effectively hard-coding a master password, which is only >>>>>>> slightly more secure than not having one in the first place, we should >>>>>>> allow the user to specify the path to a script or program that will >>>>>>> return >>>>>>> a key. In a security-conscious environment, the script might query a >>>>>>> centralised key management system to securely retrieve the key to use. >>>>>>> If a >>>>>>> user really wants the less secure implementation that this current patch >>>>>>> offers, then a simple script as follows would offer that (but would not >>>>>>> be >>>>>>> recommended): >>>>>>> >>>>>>> ==== >>>>>>> #!/bin/sh >>>>>>> >>>>>>> echo "my secret key" >>>>>>> ==== >>>>>>> >>>>>>> We would probably also want to allow use of a placeholder in which >>>>>>> the username can be passed, e.g. >>>>>>> >>>>>>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u' >>>>>>> >>>>>>> Sounds good to me. >>>>>> Does this mean we are going to remove the current implementation >>>>>> which offers a hard-coded master password? >>>>>> >>>>>>> >>>>> Yes, I think that is the way to go. I don't want to add a config >>>>> parameter that doesn't seem like a good solution, and then remove it again >>>>> in the next release. >>>>> >>>>> Ok, In that case, we need to revert the patch and also need to update >>>> the RM #7012 regarding our proposal. >>>> >>>>> >>>>> -- >>>>> Dave Page >>>>> Blog: https://pgsnake.blogspot.com >>>>> Twitter: @pgsnake >>>>> >>>>> EDB: https://www.enterprisedb.com >>>>> >>>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>> <http://edbpostgres.com> >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Software Architect | *edbpostgres.com* > <http://edbpostgres.com> > "Don't Complain about Heat, Plant a TREE" > -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com
