Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > The md5 hash which is generated for and stored in pg_shadow does not
> > use a random salt but instead uses the username which can generally be
> > determined ahead of time (especially for the 'postgres' superuser
> > account).
>
> So?
>
> The fact that we encrypt the contents of pg_shadow at all is not to
> provide security against breakins by people who have managed to
> obtain the contents of pg_shadow. Any such attacker knows as much as
> the postmaster does, and so there isn't anything much the postmaster can
> do to prevent a breakin. The reason we do it is to prevent such a
> person (or a dishonest DBA) from obtaining the user's actual original
> password. This doesn't improve the security of the database at all,
> of course, but it does improve security globally if the user used the
> same password for other systems.

A dishonest DBA would have no trouble obtaining the user's actual
original password regardless through any number of means, both technical
and social. I can go into them if you'd like but the first one would
probably be just change pg_hba.conf to say 'password' instead of 'md5'
and you're basically done.

Additionally, a dishonest DBA has no need for the original password if
the user has the same username on multiple postgres databases (not
exactly unlikely) and those postgres systems use 'md5' in pg_hba.conf.
This is because when using the 'md5' mechanism in pg_hba.conf the
original password is irrelevant, all that matters is the
password+username hash, which is exactly what's stored in pg_shadow.

Were other systems such as ssh to use this same mechanism then again for
those you would not need the original password but only the hash in
order to authenticate yourself. Thus, claiming that you're protecting
the user from a dishonest DBA is, imv, at best a false sense of
security.

> > This would allow for the pregeneration of the entire md5
> > keyspace using that 'salt' and then quick breakage of the hash once
> > it's retrieved by the attacker.
>
> Considering the size of the possible keyspace, this is pretty silly.

Not as silly as I wish it was. :/

> > Were a decent random salt of some
> > size used it would be difficult to guess and pregenerate the keyspace
> > for. Thus, keyspace generation would have to happen after pg_shadow
> > was compramised, giving the admin time to detect the compramise and
> > take corrective action.
>
> Another large assumption: that the admin knows about the compromise
> before the results are used.

It would be nice to give the admin some time to detect the compromise.
If a known salt is used then the admin gets essentially no time. If a
random salt is used then the admin will have at least some time while
the attacker generates the keyspace to find a cleartext version to pass
to the server- provided the server is using 'password' and *not* 'md5'
in pg_hba.conf. If the server is using 'md5' in pg_hba.conf then all is
lost as soon as pg_shadow is compromised.

> >. It is also not made clear that if you are
> > already handling transport-level security via SSL and/or IPSEC that
> > using md5 actually reduces security by not adding anything to the
> > transport-level security and defeating the on-disk security
> > effectivness of using md5 for pg_shadow.
>
> That's simply false. The contents of pg_shadow are never sent over the
> wire.

I didn't mean to suggest that they were. However, if you use 'md5' in
pg_hba.conf then what is stored in pg_shadow might as well be the
original password since it is all that is required to authenticate.
Sure, technically you also need the salt from the server for the
transport-md5-hash, but the server gives that to you and then all you
have to do is a simple md5hash.

> You're going to have to work a lot harder to convince us there's any
> significant issue here.

Happy to do my best. Hope this helps some. I strongly feel that using
'md5' in pg_hba.conf when using SSL or IPSEC should be strongly
discouraged. It adds nothing in that case and does some harm in the
event pg_shadow is compromised (through stealing of a backup tape, or a
partial compromise of the system whereby an attacker is able to gain
privledged access to read part of a file or similar).

Thanks,

Stephen