Re: Create Linux Script for PostgreSQL database backup

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