Postgres Pro
Downloads
Home   >   mailing lists

Re: RM1849: Auto-generating security keys - Mailing list pgadmin-hackers

From Dave Page
Subject Re: RM1849: Auto-generating security keys
Date
Msg-id CA+OCxozo4=FCjorfF8j4QH=p4iEa15Bp4P0bD5+Ch=aFY37ERg@mail.gmail.com
Whole thread Raw
In response to Re: RM1849: Auto-generating security keys  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Responses Re: RM1849: Auto-generating security keys
List pgadmin-hackers
Tree view
Hi

On Thursday, October 13, 2016, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <dpage@pgadmin.org> wrote:
Hi Ashesh,

Can you please review the attached patch, and apply if you're happy with it?
Overall the patch looked good to me.
But - I encounter an issue in 'web' mode, which wont happen with 'runtime'.

Steps for reproduction on existing pgAdmin 4 environment with 'web' mode.
- Apply the patch
- Start the pgAdmin4 application (stand alone application).
- Open pgAdmin home page.
- Log out (if already login).

And, you will see an exception.

I have figure out the issue with the patch.
We were setting the SECURITY_PASSWORD_SALT, after initializing the Security object.
Hence - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SALT properly.

Hmm.
 

I had moved the Security object initialization after fetching these configurations from the database.
I have attached a addon patch for the same.

OK, thanks.
 

Now - I run into another issue.
Because - the existing password was hashed using the old SECURITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4.

I think - we need to think about different strategy for upgrading the configuration file in the 'web' mode.
I was thinking - we can store the existing security configurations in the database during upgrade process in 'web' mode.

My concern with that is that we'll likely be storing the default config values in many cases, thus for those users, perpetuating the problem.

I guess what we need to do is re-encrypt the password during the upgrade - however, that makes me think; we then have both the key and the encrypted passwords in the same database which is clearly not a good idea. Sigh... Needs more thought. 


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgadmin-hackers by date:

Previous
From: Surinder Kumar
Date:
Subject: [pgAdmin4][Patch]: SYNONYM issue if use all special characters as name
Next
From: Dave Page
Date:
Subject: pgAdmin 4 commit: Add terst cases for packages, and update Synonym case