Re: Disabling trust/ident authentication configure option

On Tue, May 5, 2015 at 10:39 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann <volker(dot)assmann(at)gmail(dot)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.
>
>
Well "trust" actually does not sound that dangerous in case you only take a
quick glance at the documentation - "trust PostgreSQL to do the right
thing?" - so this at least requires to actively read about this, while any
person working in IT should have at least a rough understanding that weak
passwords are bad...

And trust is IMHO dangerous because even people who might know about the
dangers may choose to temporarily turn it on ("let me just finish this
update and I will worry about the authentication settings later") and then
forget to disable it again - aka it might actually be useful...

> 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.
>
>
You are right, ident is not the same "ättack vector" as trust, you most
likely won't activate this by accident, but I think it is still a dangerous
mode that would be reasonable to deactivate if it's not needed.

> 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.
>
>
Yes, passwords can be as bad as trust authentication or basically any other
method done implemented insecurely, so from my point of view the best
solution would be to be able to selectively enable/disable all
authentication methods to customize the package for specific environments.

Trust is in my point of view just the most immediately obvious "shoot
yourself in the foot" option and in my use case the thing that users are
actually bound to try and get wrong.

Please note that the patch does nothing by default, it just adds the option
to disable trust/ident but leaves them on in the standard configuration. I
do not want to disable "trust" by default for everyone, but it would be
great to have the option to do this without having to patch (and thus test
and verify) the PostgreSQL sources for each new release.

I think this is a sufficiently general requirement to warrant including an
option to disable this, as most hardening guides I have seen for PostgreSQL
unconditionally require to disable trust authentication and disabling it in
the code removes the need to check this in the runtime configuration.

> 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.
>

Single user sessions would work, but the "peer" authentication is also
still available and should be the preferred method to reset passwords when
trust is disabled, so this should not be an issue.

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