Re: Authenticate with hash instead of plaintext password? - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Authenticate with hash instead of plaintext password?
Date
Msg-id 50CE1E45.6060600@gmail.com
Whole thread Raw
In response to Re: Authenticate with hash instead of plaintext password?  (Peter Bex <Peter.Bex@xs4all.nl>)
Responses Re: Authenticate with hash instead of plaintext password?  (Peter Bex <Peter.Bex@xs4all.nl>)
List pgsql-general
On 12/16/2012 11:07 AM, Peter Bex wrote:
> On Sun, Dec 16, 2012 at 07:42:40PM +0100, Murray Cumming wrote:
>> On Sun, 2012-12-16 at 17:51 +0100, Peter Bex wrote:
>>> Hashes (if properly salted and
>>> stretched) are only useful if they are only ever checked against the
>>> password itself.  Storing a hash of any kind and comparing that directly
>>> with user input is equivalent to storing the password and comparing that
>>> with user input.
>>
>> So PostgresQL, for instance, stores the actual plaintext password (or an
>> encrypted, but not hashed) password? And compares that with the hash
>> that it receives from libpq.
>
> Hm, that's a good point, I hadn't considered that.  I don't know how
> Postgres stores its passwords internally or how its authentication works
> exactly.  Maybe one of the developers can shine a light on this.
>

http://www.postgresql.org/docs/9.2/static/encryption-options.html
"
Password Storage Encryption
By default, database user passwords are stored as MD5 hashes, so the
administrator cannot determine the actual password assigned to the user.
If MD5 encryption is used for client authentication, the unencrypted
password is never even temporarily present on the server because the
client MD5-encrypts it before being sent across the network.
"


--
Adrian Klaver
adrian.klaver@gmail.com


pgsql-general by date:

Previous
From: Peter Bex
Date:
Subject: Re: Authenticate with hash instead of plaintext password?
Next
From: Adrian Klaver
Date:
Subject: Re: PG 8.4 to 9.2 upgrade issues with ownership of large objects