Skip site navigation (1) Skip section navigation (2)

Re: [pgadmin-hackers] Client-side password encryption

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>,Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org,Andreas Pflug <pgadmin(at)pse-consulting(dot)de>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Subject: Re: [pgadmin-hackers] Client-side password encryption
Date: 2005-12-23 05:19:31
Message-ID: 43AB88E3.7020500@familyhealth.com.au (view raw or flat)
Thread:
Lists: pgadmin-hackerspgsql-hackers
>>So, can I specify the password to pg_connect() as 
>>'md5127349123742342344234'?
> 
> Certainly not.  We'd hardly be worrying about obscuring the original
> password if the encrypted version were enough to get in with.

AndrewSN can't post at the moment, but asked me to post this for him:

"Knowing the md5 hash is enough to authenticate via the 'md5' method in 
pg_hba.conf, even if you don't know the original password. Admittedly 
you have to modify libpq to do this, but this isn't going to stop an 
attacker for more than 5 seconds."

I'll add my own note that never sending the cleartext password does not 
necessarily improve PostgreSQL security, but certainly stops someone who 
sniffs the password from then using that cleartext password to get into 
other applications.  If all they can get is the md5 hash, then all they 
can get into is PostgreSQL.

Chris


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-12-23 05:39:51
Subject: Re: [pgadmin-hackers] Client-side password encryption
Previous:From: Tom LaneDate: 2005-12-23 04:31:07
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

pgadmin-hackers by date

Next:From: Tom LaneDate: 2005-12-23 05:39:51
Subject: Re: [pgadmin-hackers] Client-side password encryption
Previous:From: Tom LaneDate: 2005-12-23 04:13:07
Subject: Re: [pgadmin-hackers] Client-side password encryption

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group