Likes: 
--kK1uqZGE6pgsGNyR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Greetings,
There appears to be some deficiencies in both the documentation of the
'md5' authentication methology (in pg_hba.conf) and in the md5 hash
generation which is stored in pg_shadow.
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). 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. 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.
A larger issue, which plays into the pg_shadow storage issue somewhat,
is the lack of proper documentation of the 'md5' method of
authentication available via pg_hba.conf. When using the 'md5' method
in pg_hba.conf this is what happens:
server sends a randomly generated 'seed' to the client
client performs md5(md5(password+username)+salt) using the salt from
the server and information provided by the user and sends the result
to the server
server performs md5(hash+salt) using the salt it sent to the client
and the hash which is stored in pg_shadow.
In so doing the server has effectively made the hash which is stored
in pg_shadow the key for authentication- the user's password is no
longer necessary to authenticate to the database, only the hash from
pg_shadow is required. It is not clear in the documentation that
using 'md5' in pg_hba.conf defeats 'with encrypted password' and the
hashing in pg_shadow. 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.
It is true that while Postgres continues to use a known salt for hash
generation the effectiveness of md5 hashes in pg_shadow is reduced,
though not entirely defeated as not all have resources to generate
the keyspace for a username with a decent password (as the 'postgres'
superuser should have) or to generate the keyspace for any number of
user accounts which are the targetted accounts.
If password-based authentication is required (and other methods such
as Kerberos are unavailable), then, personally I would:
Discourage the use of 'md5' in pg_hba.conf and favor 'password'
Use good transport-level security via SSL and/or IPSEC
Change the hashing for what goes into pg_shadow to use a randomly=20
generated salt instead of the username (this would require=20
changing the protocol to allow for that randomly generated salt=20
to be provided to the client when 'md5' is being used in=20
pg_hba.conf); an alternative might be to use PAM in the meantime
Update the documetation accordingly to be clear on the issues
As soon as possible provide other hash algorithms such as sha1/2
I discussed this issue on IRC w/ some folks already though generally
they didn't appear to share my level of concern over this. My
biggest concern is that using 'md5' in pg_hba.conf reduces security
when another transport-level security mechanism is in place by a
significant amount, in my view, and this isn't clear in the
documentation.
=20
Thanks for you time, happy to answer any questions/comments on my
analysis.
Stephen
--kK1uqZGE6pgsGNyR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCZohurzgMPqB3kigRAvwpAJ9Hypfs/qD58LuqkuCB+jafXHRIZQCfRdUR
ITBH9pojFXQ2MQwPSGcgOBM=
=icX/
-----END PGP SIGNATURE-----
--kK1uqZGE6pgsGNyR--
Quote
