Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Date
Msg-id 4659.1114030998@sss.pgh.pa.us
Whole thread Raw
In response to Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
List pgsql-hackers
Stephen Frost <sfrost@snowman.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.

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

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

You're going to have to work a lot harder to convince us there's any
significant issue here.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: WAL/PITR additional items
Next
From: Greg Stark
Date:
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords