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

Greetings,
 There appears to be some deficiencies in both the documentation of the 'md5' authentication methology (in pg_hba.conf)
andin 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
whichcan generally be determined ahead of time (especially for the 'postgres' superuser account).  This would allow for
thepregeneration of the entire md5 keyspace using that 'salt' and then quick breakage of the hash once it's retrieved
bythe attacker.  Were a decent random salt of some size used it would be difficult to guess and pregenerate the
keyspacefor.  Thus, keyspace generation would have to happen after pg_shadow was compramised, giving the admin time to
detectthe 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'spassword is no longer necessary to authenticate to the database, only the hash from pg_shadow is required.  It is
notclear 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
thatusing md5 actually reduces security by not adding anything to the transport-level security and defeating the
on-disksecurity 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_shadowis reduced, though not entirely defeated as not all have resources to generate the keyspace for a username
witha decent password (as the 'postgres' superuser should have) or to generate the keyspace for any number of user
accountswhich 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
Changethe hashing for what goes into pg_shadow to use a randomly    generated salt instead of the username (this would
require   changing the protocol to allow for that randomly generated salt    to be provided to the client when 'md5' is
beingused in    pg_hba.conf); an alternative might be to use PAM in the meantime  Update the documetation accordingly
tobe 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
overthis.  My  biggest concern is that using 'md5' in pg_hba.conf reduces security  when another transport-level
securitymechanism is in place by a  significant amount, in my view, and this isn't clear in the  documentation.
Thanksfor you time, happy to answer any questions/comments on my  analysis. 
      Stephen