Thread: Client-side password encryption
Commands like CREATE USER foo PASSWORD 'bar' transmit the password in cleartext and possibly save the password in various client or server log files. I have just fixed this for psql and createuser to encrypt the password on the client side. A quick check of the pgadmin3 source code shows that you are also affected by this issue. I ask you to check where you paste cleartext passwords into SQL commands and change those to encrypt the password before sending or storing it anywhere. The required function pg_md5_encrypt() is contained in libpq. -- Peter Eisentraut http://developer.postgresql.org/~petere/
-----Original Message----- From: pgadmin-hackers-owner@postgresql.org on behalf of Peter Eisentraut Sent: Sun 12/18/2005 2:25 AM To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] Client-side password encryption > Commands like CREATE USER foo PASSWORD 'bar' transmit the password in > cleartext and possibly save the password in various client or server > log files. I have just fixed this for psql and createuser to encrypt > the password on the client side. A quick check of the pgadmin3 source > code shows that you are also affected by this issue. I ask you to > check where you paste cleartext passwords into SQL commands and change > those to encrypt the password before sending or storing it anywhere. > The required function pg_md5_encrypt() is contained in libpq. So did you just rip it from there into psql? I don't see it in the list of libpq exports so if thats not the case, on Windowsat least we'll need to change the api, and possibly the dll name as well to avoid any compatibility issues. Regards, Dave.
Dave Page wrote: > > > -----Original Message----- From: pgadmin-hackers-owner@postgresql.org > on behalf of Peter Eisentraut Sent: Sun 12/18/2005 2:25 AM To: > pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] Client-side > password encryption > > >> Commands like CREATE USER foo PASSWORD 'bar' transmit the password >> in cleartext and possibly save the password in various client or >> server log files. I have just fixed this for psql and createuser >> to encrypt the password on the client side. A quick check of the >> pgadmin3 source code shows that you are also affected by this >> issue. I ask you to check where you paste cleartext passwords into >> SQL commands and change those to encrypt the password before >> sending or storing it anywhere. The required function >> pg_md5_encrypt() is contained in libpq. > > > So did you just rip it from there into psql? I don't see it in the > list of libpq exports so if thats not the case, on Windows at least > we'll need to change the api, and possibly the dll name as well to > avoid any compatibility issues. And a prototype in libpq-fe.h wouldn't hurt either... And a macro, to enable distinguishing md5-enabled libpq versions from older versions. Regards, Andreas
The officially sanctioned function for this is now PQencryptPassword() in libpq. Please consider using it when available. I wrote: > Commands like CREATE USER foo PASSWORD 'bar' transmit the password in > cleartext and possibly save the password in various client or server > log files. I have just fixed this for psql and createuser to encrypt > the password on the client side. A quick check of the pgadmin3 source > code shows that you are also affected by this issue. I ask you to > check where you paste cleartext passwords into SQL commands and change > those to encrypt the password before sending or storing it anywhere. > The required function pg_md5_encrypt() is contained in libpq.
Peter Eisentraut wrote: > The officially sanctioned function for this is now PQencryptPassword() in > libpq. Please consider using it when available. Ok, we'll use it ASAP. But how to detect if it's available or not? Some #define PQENCRYPT_AVAILABLE 1 would be helpful. Regards, Andreas
> > The officially sanctioned function for this is now > PQencryptPassword() > > in libpq. Please consider using it when available. > > Ok, we'll use it ASAP. But how to detect if it's available or > not? Some #define PQENCRYPT_AVAILABLE 1 would be helpful. You're going to have to detect this at runtime, aren't you? With that, GetProcAddress() on win32 and whatever it's called on *nix should be the way to go? //Magnus
Magnus Hagander wrote: >>>The officially sanctioned function for this is now >> >>PQencryptPassword() >> >>>in libpq. Please consider using it when available. >> >>Ok, we'll use it ASAP. But how to detect if it's available or >>not? Some #define PQENCRYPT_AVAILABLE 1 would be helpful. > > > You're going to have to detect this at runtime, aren't you? With that, > GetProcAddress() on win32 and whatever it's called on *nix should be the > way to go? We need this at compile time, to check if the prototype is present. If it is, the function should be present in the lib we're linking to as well. IFAIR there was consense some weeks ago that libpq should be versioned on win32 too, so a libpq dev environment should have a libpq.lib that references libpq-82.dll (or newer). On *ix, standard lib versioning will do the job. Regards, Andreas
Peter Eisentraut wrote: > Am Donnerstag, 5. Januar 2006 12:40 schrieb Andreas Pflug: > >>Ok, we'll use it ASAP. But how to detect if it's available or not? Some >>#define PQENCRYPT_AVAILABLE 1 would be helpful. > > > Just use > > AC_CHECK_FUNCS(PQencryptPassword) Um, no autoconf in our win32 environment... Regards, Andreas
Am Donnerstag, 5. Januar 2006 12:40 schrieb Andreas Pflug: > Ok, we'll use it ASAP. But how to detect if it's available or not? Some > #define PQENCRYPT_AVAILABLE 1 would be helpful. Just use AC_CHECK_FUNCS(PQencryptPassword) and you will get a definition like that.