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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Tillotson <pntil(at)shentel(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Date: 2005-04-21 15:44:31
Message-ID: 20050421154431.GX29028@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> Tom Lane wrote:
> >It's worth pointing out also that adding a per-user-entry random salt
> >to the password protocol is not some kind of penalty-free magic bullet.
> >In particular it implies information leakage: I can tell from the
> >password challenge (or lack of one) whether the username I have offered
> >is valid. So rather than claiming "this is unconditionally a good thing
> >to do", you must actually provide a credible scenario that makes the
> >threat you are defending against more dangerous than the sorts of new
> >threats we'll be exposed to. So far I haven't seen a very credible
> >threat here.
>
> Ok, this made me think a bit. It's a valid point. I started off just
> thinking that you would send along the stored salt with the random
> session salt in something like the current AuthenticationMD5Password
> message, and if the user didn't exist send something faked out. But you
> would still get the information leak unless the faked out part could be
> consistent (inconsistency would imply an invalid user id), so it
> couldn't just be something random - you'd either have to make it
> algorithmic, which would kinda defeat the purpose, or keep a dictionary
> ... and we're back in much the same place we came in.

Can't keep a dictionary, of course. The algorithmic approach would
probably work- md5(username+pgsalt) where pgsalt is a random
per-installation salt, perhaps changed periodically, a random point once
a week or similar. The result of that md5 would then be truncated or
similar to provide the 'fake' salt to the client. md5's are pretty
cheap, I don't know that you could tell the difference between an md5
and a disk access (if it's not cache'd for whatever reason), esp. over a
network.

Changing the pgsalt shouldn't actually be a problem- that randomly
generated salt would change periodically anyway whenever a user changed
their password.

I'd also like to point out that this is *only* an issue for the 'md5'
authentication mechanism in pg_hba.conf, which I think should be
discouraged in favor of 'password' and SSL/IPSEC.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-04-21 16:13:47 Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Previous Message Bruce Momjian 2005-04-21 15:21:57 Re: [COMMITTERS] pgsql: Install some slightly realistic cost