Re: Disabling trust/ident authentication configure option

On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann <volker.assmann@gmail.com> wrote:
> Changing the password to something simple is immediately obvious as a
> security flaw for most people who may come across database configurations,
> but for the TRUST mode you actually need to know some background on why this
> is dangerous and when.

I frankly find that a bit difficult to swallow.  You think that
everyone knows that bad passwords are a problem, but some people might
not realize that an authentication method called "trust" might not be
secure?  I suppose that's possible, but I really think that if you
install an *authentication method* whose name means *just trust the
other guy to be telling the truth* without thinking about the
consequences of that, it's hard to have a lot of sympathy for whatever
happens afterwards.

Besides, your patch doesn't just disable "trust".  It also disables
"ident" authentication, which in some network configurations could
conceivably be more secure than password authentication.  When applied
to the local machine, "ident" actually means "peer", which has an
*excellent* chance of being more secure than password authentication.
For that matter, even "trust" might be better than "password".
Anybody who can sniff the network traffic can read the password right
off of the wire.  So either way, your PostgreSQL server is gonna get
hacked, but if you use password authentication, you might reveal a
password that is also used to protect access to something else that
used to be secure.

Personally, if I were going to start disabling authentication methods
at compile time, I'd start with password and md5.  If you are not
using SSL, and you use password or md5 authentication, you're
basically saying, well, I'm OK with somebody reading all of the data
that I'm sending and receiving over the wire, and I'm willing to take
the risk that my passwords are easily crackable or can be read
straight off the wire using wireshark, but to send your own queries
you will have to make at least some minimal effort.  If you need real
security, that is not nearly good enough.  If you don't need real
security, why bother making people hassle with a password that's not
providing any real protection?  There are some valid answers to that
question - e.g. if you are on a corporate WAN, you probably can't fire
somebody for blundering into an unprotected resource, but if somebody
goes to the trouble of cracking the password, even if it's weak, then
you can probably nail them.

For most users, though, I think password and md5 authentication serve
mostly to give people the illusion that they've secured the server.
The real security, if there is any, comes primarily from restricting
incoming connections via listen_addresses and/or operating system
mechanisms such as iptables and/or pg_hba.conf, and from requiring the
use of SSL.  Passwords are weak sauce.

A final point to consider is: what happens when you lock yourself out
of the server, like by forgetting that password?  Normally you can
recover by logging in as the postgres operating system user and then
connecting to the server using trust or peer authentication locally;
or you can make some temporary modification to pg_hba.conf to open up
trust access over the network in a carefully considered and temporary
way.  But your proposal would remove that safety hatch.  I guess you
could shut down the server and start up a single-user session to
change the password, but that means taking an outage.  Again, if you
like that trade-off, you can patch your own copy of the source code
however you like, but that doesn't sound like something I'd want to
recommend in general.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company