public inbox for [email protected]
help / color / mirror / Atom feed[pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
14+ messages / 7 participants
[nested] [flat]
* [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
@ 2022-04-11 06:29 Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Khushboo Vashi @ 2022-04-11 06:29 UTC (permalink / raw)
To: pgadmin-hackers
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.
Thanks,
Khushboo
Attachments:
[application/octet-stream] RM_7012.patch (7.2K, 3-RM_7012.patch)
download | inline diff:
diff --git a/docs/en_US/alternate_encryption_key.rst b/docs/en_US/alternate_encryption_key.rst
new file mode 100644
index 000000000..4bc470a34
--- /dev/null
+++ b/docs/en_US/alternate_encryption_key.rst
@@ -0,0 +1,33 @@
+.. _alternate_encryption_key:
+
+**********************************
+`Alternate Encryption Key`:index:
+**********************************
+
+pgAdmin would use the alternate encryption key to secure and later unlock the saved server
+passwords if the master password is disabled AND there is NO suitable key/password available
+from the authentication module for the user in server mode.
+
+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 authentication 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 master password
+is disabled pgAdmin would use the alternate encryption key, if it is set.
+
+
+.. note:: You can set the alternate encryption key by setting the configuration
+ parameter *ALTERNATE_ENCRYPTION_KEY=<Key>*.
+ See :ref:`config_py` for more information on configuration parameters and how
+ they can be changed or enforced across an organisation.
+
+.. note:: If the master password and the alternate encryption key is disabled,
+ then all the saved passwords will be removed.
+
+
+.. warning:: By setting this option, you should be fully aware of the potential security
+ risk of using the same encryption key for multiple users, that may be accessible to
+ sysadmins who would not normally be able to use pgAdmin.
+
+ It is **not recommended** that you use the alternate encryption key instead of master password
+ if you use the *Save Password* option.
diff --git a/docs/en_US/connecting.rst b/docs/en_US/connecting.rst
index 8d1a3e4cf..df1874c37 100644
--- a/docs/en_US/connecting.rst
+++ b/docs/en_US/connecting.rst
@@ -38,6 +38,13 @@ It is set by the user and can be disabled using config.
master_password
+The Alternate Encryption Key is used to secure and later unlock saved server passwords.
+It is **not recommended** to use the alternate encryption key.
+
+.. toctree::
+
+ alternate_encryption_key
+
After defining a server connection, right-click on the server name, and select
*Connect to server* to authenticate with the server, and start using pgAdmin to
manage objects that reside on the server.
diff --git a/docs/en_US/master_password.rst b/docs/en_US/master_password.rst
index ced1c7eb5..48edfdf49 100644
--- a/docs/en_US/master_password.rst
+++ b/docs/en_US/master_password.rst
@@ -5,7 +5,9 @@
************************
A master password is required to secure and later unlock the saved server
-passwords. This is applicable only for desktop mode users.
+passwords. This is applicable for desktop mode users and for the auth methods
+such as OAuth, Kerberos or Webserver where pgAdmin doesn't have access to anything
+long-lived to form the encryption key.
* You are prompted to enter the master password when you open the window for
the first time after starting the application.
@@ -23,15 +25,15 @@ passwords. This is applicable only for desktop mode users.
See :ref:`config_py` for more information on configuration parameters and how
they can be changed or enforced across an organisation.
-.. note:: If the master password is disabled, then all the saved passwords will
- be removed.
+.. note:: If the master password and :ref:`alternate_encryption_key` is disabled,
+ then all the saved passwords will be removed.
.. warning:: If the master password is disabled, then the saved passwords will
- be encrypted using a key which is derived from information within the
- configuration database. Use of a master password ensures that the encryption
- key does not need to be stored anywhere, and thus prevents possible access
- to server credentials if the configuration database becomes available to an
- attacker.
+ be encrypted using the :ref:`alternate_encryption_key` or a key which is derived
+ from information within the configuration database. Use of a master password
+ ensures that the encryption key does not need to be stored anywhere, and thus
+ prevents possible access to server credentials if the configuration database
+ becomes available to an attacker.
It is **strongly** recommended that you use the master password if you use
the *Save Password* option.
diff --git a/web/config.py b/web/config.py
index f8733fe0a..14e3b3ec0 100644
--- a/web/config.py
+++ b/web/config.py
@@ -553,6 +553,27 @@ ALLOW_SAVE_TUNNEL_PASSWORD = False
##########################################################################
MASTER_PASSWORD_REQUIRED = True
+##########################################################################
+# 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 or Kerberos, pgAdmin
+# doesn't have access to anything long-lived to form the encryption key from,
+# hence it uses the master password.
+
+# So, pgAdmin would use this alternate encryption key if
+# a) the master password is disabled
+# AND
+# b) there is NO suitable key/pass available from the auth module for the user.
+
+# By setting this option, you should fully aware of the potential security
+# risk of using the same encryption key for multiple users,
+# that may be accessible to sysadmins who would not normally
+# be able to use pgAdmin.
+##########################################################################
+ALTERNATE_ENCRYPTION_KEY = None
+
##########################################################################
# Allows pgAdmin4 to create session cookies based on IP address, so even
# if a cookie is stolen, the attacker will not be able to connect to the
diff --git a/web/pgadmin/browser/__init__.py b/web/pgadmin/browser/__init__.py
index 4a7e18eb0..4525206ee 100644
--- a/web/pgadmin/browser/__init__.py
+++ b/web/pgadmin/browser/__init__.py
@@ -750,7 +750,8 @@ def index():
auth_source = session['auth_source_manager'][
'source_friendly_name']
- if not config.MASTER_PASSWORD_REQUIRED and 'pass_enc_key' in session:
+ if not config.MASTER_PASSWORD_REQUIRED and 'pass_enc_key' in session\
+ and not config.ALTERNATE_ENCRYPTION_KEY:
session['allow_save_password'] = False
response = Response(render_template(
diff --git a/web/pgadmin/utils/master_password.py b/web/pgadmin/utils/master_password.py
index 27db924cf..ba00963a7 100644
--- a/web/pgadmin/utils/master_password.py
+++ b/web/pgadmin/utils/master_password.py
@@ -33,6 +33,9 @@ def get_crypt_key():
elif config.MASTER_PASSWORD_REQUIRED \
and enc_key is None:
return False, None
+ elif not config.MASTER_PASSWORD_REQUIRED and config.SERVER_MODE and \
+ config.ALTERNATE_ENCRYPTION_KEY:
+ return True, config.ALTERNATE_ENCRYPTION_KEY
elif not config.MASTER_PASSWORD_REQUIRED and config.SERVER_MODE and \
'pass_enc_key' in session:
return True, session['pass_enc_key']
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
@ 2022-04-11 08:19 ` Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Akshay Joshi @ 2022-04-11 08:19 UTC (permalink / raw)
To: Khushboo Vashi <[email protected]>; +Cc: pgadmin-hackers
Thanks, the patch applied.
On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
[email protected]> 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.
>
> Thanks,
> Khushboo
>
--
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres <http://edbpostgres.com>*
*Mobile: +91 976-788-8246*
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
@ 2022-04-22 08:31 ` Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Dave Page @ 2022-04-22 08:31 UTC (permalink / raw)
To: Akshay Joshi <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers
Hi
On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <[email protected]>
wrote:
> Thanks, the patch applied.
>
> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
> [email protected]> 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'
--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
@ 2022-04-22 08:57 ` Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Khushboo Vashi @ 2022-04-22 08:57 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
> Hi
>
> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <[email protected]>
> wrote:
>
>> Thanks, the patch applied.
>>
>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>> [email protected]> 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?
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
@ 2022-04-22 09:04 ` Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Dave Page @ 2022-04-22 09:04 UTC (permalink / raw)
To: Khushboo Vashi <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
[email protected]> wrote:
>
>
> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>
>> Hi
>>
>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <[email protected]>
>> wrote:
>>
>>> Thanks, the patch applied.
>>>
>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>> [email protected]> 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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
@ 2022-04-22 09:08 ` Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Khushboo Vashi @ 2022-04-22 09:08 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>
>
> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
> [email protected]> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>
>>> Hi
>>>
>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>> [email protected]> wrote:
>>>
>>>> Thanks, the patch applied.
>>>>
>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>> [email protected]> 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
>
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
@ 2022-04-22 09:48 ` Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Aditya Toshniwal @ 2022-04-22 09:48 UTC (permalink / raw)
To: Khushboo Vashi <[email protected]>; +Cc: Dave Page <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers
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 Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
[email protected]> wrote:
>
>
> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>>
>>>> Hi
>>>>
>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>> [email protected]> wrote:
>>>>
>>>>> Thanks, the patch applied.
>>>>>
>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>> [email protected]> 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"
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
@ 2022-04-22 09:58 ` Dave Page <[email protected]>
2022-04-22 10:16 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Dave Page @ 2022-04-22 09:58 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
[email protected]> 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.
>
> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
> [email protected]> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>
>>>
>>>
>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Thanks, the patch applied.
>>>>>>
>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>> [email protected]> 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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
@ 2022-04-22 10:16 ` Aditya Toshniwal <[email protected]>
2022-04-22 10:26 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Ashesh Vashi <[email protected]>
2022-04-22 10:27 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
0 siblings, 2 replies; 14+ messages in thread
From: Aditya Toshniwal @ 2022-04-22 10:16 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote:
>
>
> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
> [email protected]> 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.
>
>
>
>>
>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Thanks, the patch applied.
>>>>>>>
>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>>> [email protected]> 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"
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:16 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
@ 2022-04-22 10:26 ` Ashesh Vashi <[email protected]>
1 sibling, 0 replies; 14+ messages in thread
From: Ashesh Vashi @ 2022-04-22 10:26 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Dave Page <[email protected]>; Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, Apr 22, 2022 at 3:46 PM Aditya Toshniwal <
[email protected]> wrote:
>
>
> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>> [email protected]> 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.
>
Environment variables are good for static values.
Here - we're talking about dynamic data (per user security key), hence -
hooks are the best way forward.
-- Ashesh
>
>>
>>
>>>
>>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Thanks, the patch applied.
>>>>>>>>
>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>>>> [email protected]> 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"
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:16 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
@ 2022-04-22 10:27 ` Dave Page <[email protected]>
2022-04-22 10:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
1 sibling, 1 reply; 14+ messages in thread
From: Dave Page @ 2022-04-22 10:27 UTC (permalink / raw)
To: Aditya Toshniwal <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal <
[email protected]> wrote:
>
>
> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>> [email protected]> 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 <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Thanks, the patch applied.
>>>>>>>>
>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>>>> [email protected]> 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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:16 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 10:27 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
@ 2022-04-22 10:31 ` Aditya Toshniwal <[email protected]>
2023-05-03 09:44 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Yogesh Mahajan <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Aditya Toshniwal @ 2022-04-22 10:31 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers
On Fri, Apr 22, 2022 at 3:57 PM Dave Page <[email protected]> wrote:
>
>
> On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal <
> [email protected]> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote:
>>
>>>
>>>
>>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>>> [email protected]> 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 <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Thanks, the patch applied.
>>>>>>>>>
>>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>>>>> [email protected]> 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"
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:16 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 10:27 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
@ 2023-05-03 09:44 ` Yogesh Mahajan <[email protected]>
2023-05-03 13:41 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Yogesh Mahajan @ 2023-05-03 09:44 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers; Aditya Toshniwal <[email protected]>
Hi Dave/Team,
As per the new design, pgAdmin should add a config to specify a path for
script/program to retrieve an encryption key & use it to encrypt the
passwords.
The script/program will be at an application level and not a user level.
This feature will be applicable only in case of server mode as we are going
to use OS level secret storage for the same in Desktop mode.
Thanks,
Yogesh Mahajan
EnterpriseDB
On Fri, Apr 22, 2022 at 4:01 PM Aditya Toshniwal <
[email protected]> wrote:
>
> On Fri, Apr 22, 2022 at 3:57 PM Dave Page <[email protected]> wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>>>> [email protected]> 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 <
>>>>> [email protected]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks, the patch applied.
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>>>>>> [email protected]> 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"
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 08:57 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 09:08 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:16 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2022-04-22 10:27 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Dave Page <[email protected]>
2022-04-22 10:31 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Aditya Toshniwal <[email protected]>
2023-05-03 09:44 ` Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Yogesh Mahajan <[email protected]>
@ 2023-05-03 13:41 ` Dave Page <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Dave Page @ 2023-05-03 13:41 UTC (permalink / raw)
To: Yogesh Mahajan <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers; Aditya Toshniwal <[email protected]>
On Wed, 3 May 2023 at 10:45, Yogesh Mahajan <[email protected]>
wrote:
> Hi Dave/Team,
>
> As per the new design, pgAdmin should add a config to specify a path for
> script/program to retrieve an encryption key & use it to encrypt the
> passwords.
>
Right.
> The script/program will be at an application level and not a user level.
> This feature will be applicable only in case of server mode as we are going
> to use OS level secret storage for the same in Desktop mode.
>
Yes. However, we can pass parameters to the hook. For example, we might do
something like:
MASTER_PASSWORD_HOOK = '/path/to/key_client.sh %U %E'
Where at runtime %U is replaced with the username and %E is replaced with
the user's email address.
Those are just examples of course - there may be other parameters that make
sense to make available.
>
> Thanks,
> Yogesh Mahajan
> EnterpriseDB
>
>
> On Fri, Apr 22, 2022 at 4:01 PM Aditya Toshniwal <
> [email protected]> wrote:
>
>>
>> On Fri, Apr 22, 2022 at 3:57 PM Dave Page <[email protected]> wrote:
>>
>>>
>>>
>>> On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>>>>> [email protected]> 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 <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks, the patch applied.
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>>>>>>>>> [email protected]> 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"
>>
>
--
Dave Page
VP, Chief Architect, Database Infrastructure
Blog: https://www.enterprisedb.com/dave-page
Twitter: @pgsnake
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2023-05-03 13:41 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]>
2022-04-11 08:19 ` Akshay Joshi <[email protected]>
2022-04-22 08:31 ` Dave Page <[email protected]>
2022-04-22 08:57 ` Khushboo Vashi <[email protected]>
2022-04-22 09:04 ` Dave Page <[email protected]>
2022-04-22 09:08 ` Khushboo Vashi <[email protected]>
2022-04-22 09:48 ` Aditya Toshniwal <[email protected]>
2022-04-22 09:58 ` Dave Page <[email protected]>
2022-04-22 10:16 ` Aditya Toshniwal <[email protected]>
2022-04-22 10:26 ` Ashesh Vashi <[email protected]>
2022-04-22 10:27 ` Dave Page <[email protected]>
2022-04-22 10:31 ` Aditya Toshniwal <[email protected]>
2023-05-03 09:44 ` Yogesh Mahajan <[email protected]>
2023-05-03 13:41 ` Dave Page <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox