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. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com
