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. Thanks, Vipin Sent from my iPhone |
I can tell you what we used do where I work. I don't know if this is something which would work for everyone. We didn't have a static .pgpass file, instead we stored the
encrypted
password in another location, and our application generated a .pgpass file with the plaintext password in it for the purpose of establishing the connection, then removed the file as soon as possible. What we do now is used cert-based authentication using a similar process to create an unecrypted private key file at the last moment, and remove it immediately. |
In reply to this post by Vipin Madhusoodanan
Vipin Madhusoodanan <[hidden email]> 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. |
On Wed, Feb 24, 2021 at 11:27:45AM +1100, Tim Cross <[hidden email]> wrote:
> Vipin Madhusoodanan <[hidden email]> 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. But it's only secure when the computer is powered down (i.e. if it is physically stolen, or the disk is physically removed). It provides no security for a computer that is up and running, and compromised. But that might satisfy the parties that make up the requirements. It all depends on the threat model that they need to address. So it can be easy to do, but does it satisfy your requirements? If so, encrypt the file system (and know that it isn't secure). If not, maybe Hashicorp's Vault product, or clevis and tang, could be used to store passwords instead of putting them in a .pgpass file. cheers, raf |
On 2/23/21 10:42 PM, raf wrote:
[snip] > 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. > > But it's only secure when the computer is powered down > (i.e. if it is physically stolen, or the disk is > physically removed). It provides no security for a > computer that is up and running, and compromised. > > But that might satisfy the parties that make up the > requirements. It all depends on the threat model that > they need to address. I see the same thing when SQL Server systems are audited. One of the check boxes is "encrypted database". I say, "encrypt columns, and modify the application to decrypt the columns"; the customer laughs, and asks about TDE, which I implement. Of course, these systems are VMs and SQL Server is rarely turned off, so it serves no practical purpose other than to encrypt the backups. Auditors don't understand that, hear "it's encrypted" and are happy when I show them AES-128 and that I rotate the key yearly. -- Angular momentum makes the world go 'round. |
In reply to this post by raf-6
raf <[hidden email]> writes: > On Wed, Feb 24, 2021 at 11:27:45AM +1100, Tim Cross <[hidden email]> wrote: > >> Vipin Madhusoodanan <[hidden email]> 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 |
Thank you all for the valuable inputs. We will work on integrating with our password vault and eliminate using pgpass file for authentication. Thanks, Vipin On Wed, Feb 24, 2021, 12:12 AM Tim Cross <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |