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

From Andrew Dunstan
Subject Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Date
Msg-id 4267C200.6080109@dunslane.net
Whole thread Raw
In response to Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers

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.


cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Install some slightly realistic cost estimation
Next
From: Tom Lane
Date:
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords