Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bv6GV-0004BT-EG for pgadmin-hackers@arkaria.postgresql.org; Fri, 14 Oct 2016 17:27:27 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bv6GU-0002Hf-9r for pgadmin-hackers@arkaria.postgresql.org; Fri, 14 Oct 2016 17:27:26 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bv6GT-0002HZ-Ss for pgadmin-hackers@postgresql.org; Fri, 14 Oct 2016 17:27:26 +0000 Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bv6GR-0000oM-4C for pgadmin-hackers@postgresql.org; Fri, 14 Oct 2016 17:27:24 +0000 Received: by mail-it0-x22d.google.com with SMTP id o19so17192462ito.1 for ; Fri, 14 Oct 2016 10:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fpdc9xqA1c3M4xNdoj2/JJgfhJd0yILOfFAJsmx16Vo=; b=rzU2IoYvuWaUbdUjIb0TgmIBut0zsECI+pMJFXPDqlm0Idkti7rghGF2kkV4A7gy8u S1ZmkPtEAek3gEJPcM8OIeF4513sFKeMJQJMYNLgAVjqZrKFa4Y60HQwnpqj+EpUk8Qr DajRUiK6jn/667akrXcGxksDPoceve5fxw0NlzfjMvmd8Reb+oxhHq2QJcU1IQSoYFR9 2tzeASVUMwPfH0qR0MZ5EWLnO98Sp7S2+f/NCQ/UppdMpfb8smpdWzQHxR2mfsWo6bFq 8+G08Ihppr3JT5c/l9N6RVEgtHYFwXYHTo0z1mxSYZC1TYU6aZbO841cx0VFeGZwU9vV bTeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fpdc9xqA1c3M4xNdoj2/JJgfhJd0yILOfFAJsmx16Vo=; b=ijQaQMp+HrvzUbCAMBXnTOrRTai2W9HRRWFLz3KVYe16FF0LL2tEUORgKGDBd+Aim9 421S7Hh4bxJWVgmhKvglXmnGtBHbAPwqAFU1tKCim0bcSXH+4OMGN6R23G8U313ACUM8 8NcNebQua8YZ1hutbJzKDm637tRMYvTuBhI1NJaQRM489t2e1yav0qrUYu261ZoXuZIZ UnYnzfFZsVv4oSSpsrcNEEGux+HVVI/sO1fgs830T3a0QDfyqCK/1hFqjytlCTR0bZYv ulhoizKKubpLB+wK6TJoQDMDe+AtIVtU9QKndUGxogCsWtvbB0SZLARddffsu1WHhQhS o1dg== X-Gm-Message-State: AA6/9RlMGEya5TMt3QJcd82cGyZcymnKWigCA9/Vk00AOjNqRh4d00O00crzzaWNkeq72xJKix8pjsmXHNFt8g== X-Received: by 10.36.6.130 with SMTP id 124mr2832600itv.94.1476466042026; Fri, 14 Oct 2016 10:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.146.135 with HTTP; Fri, 14 Oct 2016 10:27:19 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Fri, 14 Oct 2016 18:27:19 +0100 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Ashesh Vashi Cc: pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= Content-Type: multipart/alternative; boundary=001a1143758af552ae053ed6891f X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a1143758af552ae053ed6891f Content-Type: text/plain; charset=UTF-8 Hi On Thursday, October 13, 2016, Ashesh Vashi wrote: > Hi Dave, > > On Tue, Oct 11, 2016 at 9:10 PM, Dave Page > 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 --001a1143758af552ae053ed6891f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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@pga= dmin.org> wrote:
Hi Ashes= h,

Can you please review the attached patch, and apply i= f you're happy with it?
Overall the patch looked= good to me.
But - I encounter an issue in 'web' mode, wh= ich 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 exceptio= n.

I have figure out the issue with the patch.
We were setting the SECURITY_PASSWORD_SALT, after initializing the S= ecurity object.
Hence - it could not set the SECURITY_KEY, and SE= CURITY_PASSWORD_SALT properly.
Hmm.
=C2=A0

=
I had moved the Security object initialization after fetching th= ese configurations from the database.
I have attached a addon pat= ch for the same.

OK= , thanks.
=C2=A0

<= div>Now - I run into another issue.
Because - the existing passwo= rd was hashed using the old SECURITY_PASSWORD_SALT, I am no more able to lo= gin to pgAdmin 4.

I think - we need to think about= different strategy for upgrading the configuration file in the 'web= 9; mode.
I was thinking - we can store the existing security conf= igurations 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 p= asswords in the same database which is clearly not a good idea. Sigh... Nee= ds more thought.=C2=A0


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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterp= rise PostgreSQL Company

--001a1143758af552ae053ed6891f--