Re: Create Linux Script for PostgreSQL database backup - Mailing list pgsql-admin
From | Christopher Browne |
---|---|
Subject | Re: Create Linux Script for PostgreSQL database backup |
Date | |
Msg-id | m3n0086um4.fsf@wolfe.cbbrowne.com Whole thread Raw |
In response to | Re: Create Linux Script for PostgreSQL database backup (Naomi Walker <nwalke@eldocomp.com>) |
List | pgsql-admin |
Centuries ago, Nostradamus foresaw when nwalke@eldocomp.com (Naomi Walker) would write: > Anything would plain text would be a problem. Isnt .pgpass plain > text? Yes, it's plain text. How do you propose to improve on that? At _some_ point, there has GOT to be a password in plain text form that libpq has access to, and any attempt to obfuscate it cannot provide anything better than illusory security. Suppose we decide we will store it in some "encrypted" form; libpq (or some equivalent) necessarily has _got_ to contain the decryption system, which means that anyone that can read the library and therefore read that decryption key, allowing them to decrypt the file containing the "encrypted" password. In effect, we could _pretend_ to encrypt the passwords in .pgpass, but it can't possibly provide any more security than we get storing them unencrypted. Suppose we characterize this in a sort of mathematical notation... P - plaintext password E: p ==> p' is an function mapping text into an "encrypted" form E':p' ==> p is the inverse function of E, mapping the encrypted form back into plaintext You propose that we store an encrypted form in the password file. That means that we have some tool that takes P, transforms it using function E to E(P), and puts it in the encrypted password file. But then there must be an instance of function E' either in libpq or within the postmaster. If I have access to the computer system, I therefore have access to libpq+postmaster, and thus can take that encrypted password, E(P), and use E' to find E'(E(P)) = P. That's the plaintext password; you imagined it hidden, but it wasn't, really. Public key encryption, while seemingly magical for many purposes, doesn't help with this. Functions E and E' could both be PK-related; the fact that E' MUST exist on the system means that E/E' can provide no meaningful security. This is a fundamental flaw that strikes just about any such sort of automated process that cannot resort to asking an operator for a "key." (There's an exception, bt it requires having a tamper-resistant cryptographic device connected to the computer system, and those are really expensive to manage.) I do prefer secure systems to those that aren't, but I also engage a healthy distrust in people that tell me things that I know aren't true. If someone were to claim that encrypting these passwords provided material improvements to security, they would either be lying to me, or demonstrating that they don't understand what security this would(n't) provide. If PostgreSQL Core folk claimed that encrypting the passwords provided improved security, I'd have to think uncomplimentary thoughts about them... -- (format nil "~S@~S" "cbbrowne" "cbbrowne.com") http://www3.sympatico.ca/cbbrowne/advocacy.html Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it. -- Richard Feynman
pgsql-admin by date: