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

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

From
"Dave Page"
Date:

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 19 December 2005 05:37
> To: Christopher Kings-Lynne
> Cc: Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas
> Pflug; Dave Page
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
> Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> >> So it appears that pg_md5_encrypt is not officially
> exported from libpq.
> >> Does anyone see a problem with adding it to the export
> list and the
> >> header file?
>
> > Is it different to normal md5?  How is this helpful to the
> phpPgAdmin
> > project?
>
> It would be better to export an API that is (a) less random (why one
> input null-terminated and the other not?) and (b) less tightly tied
> to MD5 --- the fact that the caller knows how long the result must be
> is the main problem here.
>
> Something like
>     char *pg_gen_encrypted_passwd(const char *passwd, const
> char *user)
> with malloc'd result (or NULL on failure) seems more future-proof.

Changing the API is likely to cause fun on Windows for new apps that
find an old libpq.dll. Perhaps at this point it should become
libpq82.dll?

Regards, Dave.


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

From
Martijn van Oosterhout
Date:
On Mon, Dec 19, 2005 at 08:51:23AM -0000, Dave Page wrote:
> > Something like
> >     char *pg_gen_encrypted_passwd(const char *passwd, const
> > char *user)
> > with malloc'd result (or NULL on failure) seems more future-proof.
>
> Changing the API is likely to cause fun on Windows for new apps that
> find an old libpq.dll. Perhaps at this point it should become
> libpq82.dll?

Hmm? Libpq already has a version number, I beleive it's upto 4.1 right
now. So if any number is used, it should be that. And secondly, there
have already been new functions added to the API without changing the
library name so why should that happen here?

In windows the trend seems to be to upgrade a library if the one on the
system is too old. If programs are really worried about it, they should
lookup the function dynamically rather than statically...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

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

From
Christopher Kings-Lynne
Date:
By the way,

I've already implemented this in phpPgAdmin trivially using the md5() 
function.  I can't be bothered using a C library function :D

Chris

Dave Page wrote:
>  
> 
> 
>>-----Original Message-----
>>From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
>>Sent: 19 December 2005 05:37
>>To: Christopher Kings-Lynne
>>Cc: Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas 
>>Pflug; Dave Page
>>Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password 
>>encryption 
>>
>>Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>>
>>>>So it appears that pg_md5_encrypt is not officially 
>>
>>exported from libpq.  
>>
>>>>Does anyone see a problem with adding it to the export 
>>
>>list and the 
>>
>>>>header file?
>>
>>>Is it different to normal md5?  How is this helpful to the 
>>
>>phpPgAdmin 
>>
>>>project?
>>
>>It would be better to export an API that is (a) less random (why one
>>input null-terminated and the other not?) and (b) less tightly tied
>>to MD5 --- the fact that the caller knows how long the result must be
>>is the main problem here.
>>
>>Something like
>>    char *pg_gen_encrypted_passwd(const char *passwd, const 
>>char *user)
>>with malloc'd result (or NULL on failure) seems more future-proof.
> 
> 
> Changing the API is likely to cause fun on Windows for new apps that
> find an old libpq.dll. Perhaps at this point it should become
> libpq82.dll?
> 
> Regards, Dave.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq



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

From
Alvaro Herrera
Date:
Christopher Kings-Lynne wrote:
> By the way,
> 
> I've already implemented this in phpPgAdmin trivially using the md5() 
> function.  I can't be bothered using a C library function :D

IIRC the whole point of this exercise was to avoid passing the password
to the server in the first place.  Unless you are talking about a PHP
md5() password of course ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


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

From
Christopher Kings-Lynne
Date:
>>I've already implemented this in phpPgAdmin trivially using the md5() 
>>function.  I can't be bothered using a C library function :D
> 
> IIRC the whole point of this exercise was to avoid passing the password
> to the server in the first place.  Unless you are talking about a PHP
> md5() password of course ...

Yes...

However of course in phpPgAdmin the password has already been sent 
cleartext to the webserver from your browser, and the database 
connection password parameter is still sent in the clear so...

Chris



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

From
Christopher Kings-Lynne
Date:
> IIRC the whole point of this exercise was to avoid passing the password
> to the server in the first place.  Unless you are talking about a PHP
> md5() password of course ...
>