Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lEnPm-0000Gg-3i for pgsql-admin@arkaria.postgresql.org; Wed, 24 Feb 2021 06:12:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lEnPk-0004JS-Lw for pgsql-admin@arkaria.postgresql.org; Wed, 24 Feb 2021 06:12:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lEnPk-0004JK-Cf for pgsql-admin@lists.postgresql.org; Wed, 24 Feb 2021 06:12:48 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lEnPh-0004H1-Jr for pgsql-admin@lists.postgresql.org; Wed, 24 Feb 2021 06:12:47 +0000 Received: by mail-pl1-x632.google.com with SMTP id k22so566884pll.6 for ; Tue, 23 Feb 2021 22:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=gjJlnHqG8zcxgtjnRUXpNUb11fOKR42v2ClBq3GItdw=; b=Vjgi9bq3hR90Gt02esgbJmh5QI/uzCLGBh/PZKv2LYEIdjYhq3FgCMJdPG6mOKPZGF suApR9Ku8nxu4w3inuQFj37k53k4KibiOek3wu0U/sTqM7Ag8AB4JLJL2G6Nl3albJVk HTDvIdZbdpBKTUUUqzErNIj8xsUZPzY8tHyZ9/L+rrE0Iy0+pwAdxZ+ilQ8W3F9RkUfC Zpmxc6eQU3C0otL5dqFV52wWzJi0Bucvw7QxvBtteOYH9KJKS7kPzIFGncurpzk4cMcJ CoddRhtdS5XhkJtQEPeqrQOTTYuHfkVExOU/0Zcncv5iYxNDkTEaIRiGcyZUeaZvi5WP znBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=gjJlnHqG8zcxgtjnRUXpNUb11fOKR42v2ClBq3GItdw=; b=NUC5vLDzHi08oOYJq1qND3+TGT3icZMKysTJcNw8367uBWWPtYLFhu2mSGeDzdG54J AxspzjnWWHA/QqUrNGeYtsAJ3qqZ0LRN3FUGyQ2owXtkkNQMwOPXWCiLKw3zFOXPzmZi 5x3veLnLuK3NugKL6x84qp26SSj8cA99Pn4m0GoWTVH0h9FbdKBB3Y9jXuCOpehqwkhz /lPNtCrY+SfDs+GvW1QtmB3QArE+eE+huojTgbXknIoFxZUICAsQC4Jdp4BgTKZ7uV08 KchaXcMNFw2C47i448XQ+v4ve+x1zZ/cu7ju5/epk2x/xKXwM8MCIIgppmwExm2lkmnx rybA== X-Gm-Message-State: AOAM532E5RBS0ppq39bDVVrhsbF93AXwIlC1+HIPMzwDh3MkjU+PNYN2 YburT9ZP2AvQeIQMlb0SPVJcA6f3bro= X-Google-Smtp-Source: ABdhPJxAQpBM+DGj7N4n4J4cJD8cXt/Xx1VomgDt5wO+x3fAsH5n2uOauJ4MpkFWEVbFlLaQmhxA9A== X-Received: by 2002:a17:902:8ec1:b029:dc:8ae1:7a22 with SMTP id x1-20020a1709028ec1b02900dc8ae17a22mr6280417plo.6.1614147163388; Tue, 23 Feb 2021 22:12:43 -0800 (PST) Received: from tim-desktop (106-69-122-55.dyn.iinet.net.au. [106.69.122.55]) by smtp.gmail.com with ESMTPSA id b22sm1220984pfo.23.2021.02.23.22.12.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Feb 2021 22:12:43 -0800 (PST) References: <87eeh6xnyy.fsf@gmail.com> <20210224044223.7cwkbced3ticu6bk@raf.org> User-agent: mu4e 1.5.8; emacs 27.1.91 From: Tim Cross To: raf Cc: pgsql-admin@lists.postgresql.org Subject: Re: How to encrypt password in pgpass file Date: Wed, 24 Feb 2021 17:04:35 +1100 In-reply-to: <20210224044223.7cwkbced3ticu6bk@raf.org> Message-ID: <87blcaxaco.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk raf writes: > On Wed, Feb 24, 2021 at 11:27:45AM +1100, Tim Cross wrote: > >> Vipin Madhusoodanan writes: >> >> > Hi Team, >> > >> > We have a security requirement to encrypt passwords in .pgpass file. Could you please advise on the options and steps to be followed to achieve this. >> > >> >> Basically, don't use .pgpass. I think .pgpass should be viewed as old >> legacy solution which is not terribly compatible with today's security >> requirements. I don't think there is support for encrypting the .pgpass >> file. Even if you could encrypt the .pgpass file, you would then need to >> decrypt it with a passpharase anyway (you could have a key which has no >> passpharase, but if that is on the same system, what have you achieved >> apart from a false sense of security). >> >> How to best solve your requirement depends on the specifics of your >> requirement. However, often you can implement something more secure by >> using environment variables which are set for the process the psql (or >> whatever) command executes in. The value for the variable can be >> obtained from a secure source, such as a keyring, ldap server, gpg >> encrypted file etc. > > Sometimes, the security requirements are for > encryption-at-rest, and it doesn't particularly matter > if encryption-at-rest is actually secure against likely > threats (sadly). > > For example, you could use file system encryption (e.g. > ecryptfs/LUKS/Linux, FileVault/macOS, > BitLocker/Windows). Then all of your files are > encrypted at rest, including .pgpass. > Yep, exactly why I said it depends on the specifics of your requirements. The sad truth is there are some really poor 'security experts' out there and a lot of snake oil sellers making ridiculous sums of money for providing poor advice. Often, it is just a box ticking exercise that does little to improve, sometimes even weakens, security. My guess with this one is it is probably something like "No passwords will be stored as plain text" or even worse, all passwords must be encrypted, which is funny when you think most passwords are not envrypted, but instead stored as 1-way hashes. -- Tim Cross