Re: MD5 authentication needs help - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: MD5 authentication needs help
Date
Msg-id A737B7A37273E048B164557ADEF4A58B365A396C@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to Re: MD5 authentication needs help  (Stephen Frost <sfrost@snowman.net>)
Responses Re: MD5 authentication needs help
List pgsql-hackers
Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Let me update my list of possible improvements:
>>
>>> 1)  MD5 makes users feel uneasy (though our usage is mostly safe)
>>
>>> 2)  The per-session salt sent to the client is only 32-bits, meaning
>>> that it is possible to reply an observed MD5 hash in ~16k connection
>>> attempts.
>>
>>> 3)  Using the user name for the MD5 storage salt allows the MD5 stored
>>> hash to be used on a different cluster if the user used the same
>>> password.
>>
>>> 4)  Using the user name for the MD5 storage salt allows the MD5 stored
>>> hash to be used on the _same_ cluster.
>>
>>> 5)  Using the user name for the MD5 storage salt causes the renaming of
>>> a user to break the stored password.
>>
>> What happened to "possession of the contents of pg_authid is sufficient
>> to log in"?  I thought fixing that was one of the objectives here.
> 
> Yes, it certainly was.  I think Bruce was thinking that we could simply
> hash what goes on to disk with an additional salt that's stored, but
> that wouldn't actually work without requiring a change to the wireline
> protocol, which is the basis of this entire line of discussion, in my
> view.

This article
https://hashcat.net/misc/postgres-pth/postgres-pth.pdf
has some ideas about how to improve the situation.

Yours,
Laurenz Albe

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: INSERT ... ON CONFLICT UPDATE and RLS
Next
From: Fabien COELHO
Date:
Subject: extend pgbench expressions with functions