On Fri, Apr 22, 2022 at 3:57 PM Dave Page <dp...@pgadmin.org> wrote: > > > 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. >
Got it. Thanks. > > > >> >>> >>> >>>> >>>> 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 > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Software Architect | *edbpostgres.com* <http://edbpostgres.com> "Don't Complain about Heat, Plant a TREE"
