bugtraq - Re: Postgres: pg_hba.conf, md5, pg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 20 Apr 2005 17:03:18 -0400
From: Tom Lane <tgl@....pgh.pa.us>
To: Stephen Frost <sfrost@...wman.net>
Cc: pgsql-hackers@...tgresql.org, bugtraq@...urityfocus.com
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords

Stephen Frost <sfrost@...wman.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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org