Stephen Frost <sfrost@xxxxxxxxxxx> writes: > Greetings, > > * Tim Cross (theophilusx@xxxxxxxxx) wrote: >> I suspect it is unlikely you will ever see a .pgpass solution which >> supports encryption. There are just too many 'chicken and egg' problems >> - you need a key to encrypt the .pgpass file, but now you need to store >> the key securely. Problem made more difficult because different >> platforms all do this in different ways and with different levels of >> sophistication. While it could be done, the amount of work required is >> probably more than the desire for anyone to implement it (not a big >> enough itch). > > I generally agree with most of what you had here, but to this point I > disagree- it'd actually be quite useful for libpq to gain capabilities > in this regard, as it's something that developers these days are clearly > interesting in having provided by a library (up to and including vault > solution integration, which is becoming more and more a standardized > thing, in order to get the needed key), so I dislike the implication > that we won't do that or that we'd look down on a patch which moved us > towards such a solution. There's certainly some of us in this community > who would very much look positively on such a patch. > I certainly didn't mean to imply anyone would 'look down on a patch'. However, I am sceptical about such a feature being added to PG and supported on all supported platforms. The amount of work is non-trivial, complex and difficult to get right. I'm also not sure trying to provide this functionality at the PG level is the correct way to go. Adding functionality within PG to support external solutions would be beneficial and more achievable, but implementing a full solution less so. The biggest challenge for security is complexity. In environments where you find formal security policies, the environment is typically complex with multiple systems, not just PG, requiring secure 'vaults' for passwords and keys. The last thing you want is multiple separate solutions. You want one solution which works across all your systems, is easy to maintain and keep secure and easy to audit/monitor etc. Adding multiple different solutions only adds to complexity. You don't want one system for managing PG credentials, another system for managing web credentials, another system for managing server credentials etc. You want one solution. I know some will argue this is bad because it puts all your eggs in one basket and this is a risk. However, the reality is, most places simply don't have sufficient resources to manage multiple baskets in a secure manner and often, once one basket is compromised, the others will soon follow. There are two big challenges in security. The first is preventing compromise and it tends to get a lot of attention. The second and just as important, is monitoring and becoming aware of compromise. This is often overlooked and when you examine the history of data breaches, you notice that in all of the most sever examples, a common thread is the organisation was unaware of the compromise for some time. Having multiple baskets creates policy and process complexity, increases the amount of monitoring and auditing required and will generally reduce overall security. Providing additional APIs and facilities in libpq and other areas of PG to support external vaults would be useful. Adding secure vault implementations to PG less so. -- Tim Cross
