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.
