Обсуждение: Re: [pgadmin-hackers] Client-side password encryption
> -----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.
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.
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
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.
>>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
> 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 ... >