Re: Client-side password encryption

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

Andreas Pflug wrote:

Dave Page wrote:

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.

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?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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?

Chris

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.

regards, tom lane

-----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/

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog@svana.org]
Sent: 19 December 2005 08:59
To: Dave Page
Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
pgsql-hackers@postgresql.org; Andreas Pflug
Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
encryption

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.

Good point

And secondly, there
have already been new functions added to the API without changing the
library name so why should that happen here?

Because I suspect Tom hasn't suffered from 'dll hell' as a non-Windows
user, and because noone else noticed.

In windows the trend seems to be to upgrade a library if the
one on the
system is too old.

Yes, however it's possible that there might be multiple copies of a dll
on a single system. The search order for the DLLs has changed over the
years and over different Windows versions though, so it's not infeasible
for an app to upgrade one copy, but then load a different one when it
runs. It shouldn't affect pgAdmin, psqlODBC or pgInstaller because we
keep the DLLs local to the .exe's which is always first in the search
path, but other apps might suffer.

If programs are really worried about it,
they should
lookup the function dynamically rather than statically...

For the sake of a simple name change?

Regards, Dave.

On Mon, Dec 19, 2005 at 09:16:19AM -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.

If programs are really worried about it, they should lookup the
function dynamically rather than statically...

For the sake of a simple name change?

The function as stated above doesn't exist yet, so we're adding a new
function, not changing the name of one. The function that started the
thread is not even exported by libpq so changing that shouldn't affect
anybody. Besides, this whole discussion is moot until someone writes
such a function.

As for Windows DLL hell, I don't know a lot about that, but if that's
such a problem, why didn't the original creators of the windows port
stick the version number in there from the start. On UNIX, libpq is
half versioned (the library is, but not the symbols) so I would have
thought copying that idea would have been obvious.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog@svana.org]
Sent: 19 December 2005 09:38
To: Dave Page
Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
pgsql-hackers@postgresql.org; Andreas Pflug
Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
encryption

On Mon, Dec 19, 2005 at 09:16:19AM -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.

If programs are really worried about it, they should lookup the
function dynamically rather than statically...

For the sake of a simple name change?

The function as stated above doesn't exist yet, so we're adding a new
function, not changing the name of one. The function that started the
thread is not even exported by libpq so changing that shouldn't affect
anybody. Besides, this whole discussion is moot until someone writes
such a function.

You missunderstand me - we were asked to start using the function in
third party apps and I pointed out that it wasn't exported so we
couldn't. Tom suggested exporting an API friendly version.

As for the name, I meant the DLL name, not the function name.

As for Windows DLL hell, I don't know a lot about that, but if that's
such a problem, why didn't the original creators of the windows port
stick the version number in there from the start. On UNIX, libpq is
half versioned (the library is, but not the symbols) so I would have
thought copying that idea would have been obvious.

Because we simply didn't think of it at the time, and it's something
that has irked me ever since.

Regards, Dave.

On Mon, Dec 19, 2005 at 10:32:03AM -0000, Dave Page wrote:

As for Windows DLL hell, I don't know a lot about that, but if that's
such a problem, why didn't the original creators of the windows port
stick the version number in there from the start. On UNIX, libpq is
half versioned (the library is, but not the symbols) so I would have
thought copying that idea would have been obvious.

Because we simply didn't think of it at the time, and it's something
that has irked me ever since.

In that case, I agree. I've always thought a lot of problem in windows
could be solved if they systematically added a version number to every
library (like in UNIX).

Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

-----Original Message-----
From: Martijn van Oosterhout [mailto:kleptog@svana.org]
Sent: 19 December 2005 10:42
To: Dave Page
Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
pgsql-hackers@postgresql.org; Andreas Pflug
Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
encryption

In that case, I agree. I've always thought a lot of problem in windows
could be solved if they systematically added a version number to every
library (like in UNIX).

Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...

Not that I can think of.

Regards, Dave

As for Windows DLL hell, I don't know a lot about that, but if
that's such a problem, why didn't the original creators of the
windows port stick the version number in there from the start. On
UNIX, libpq is half versioned (the library is, but not

the symbols)

so I would have thought copying that idea would have been obvious.

Because we simply didn't think of it at the time, and it's

something

that has irked me ever since.

In that case, I agree. I've always thought a lot of problem
in windows could be solved if they systematically added a
version number to every library (like in UNIX).

Are there any reasons why we shouldn't change the libname
with every release like for UNIX? I can't think of any, but
you never know...

Yes.
If FooApp is compiled against 8.0, it will then be unable to run if you
upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
version if it's just a minor version upgrade (correct me if I'm wrong).
On windows, it will break with an ugly dialog box. Which is why DLL
renames are usually only done for backwards incompatible changes.

//Magnus

On Mon, Dec 19, 2005 at 01:07:26PM +0100, Magnus Hagander wrote:

If FooApp is compiled against 8.0, it will then be unable to run if you
upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
version if it's just a minor version upgrade (correct me if I'm wrong).
On windows, it will break with an ugly dialog box. Which is why DLL
renames are usually only done for backwards incompatible changes.

Not quite, in UNIX you have a SONAME which is the file you search for
at runtime. This might end up being symlinked to a different version
than the one you linked against.

The argument for the name change is that then you can have both the old
version and the new versions installed at the same time. So when you
"upgrade" to 8.1, you don't actually remove the old libpq but keep both
around. Then programs using either will continue to work. On UNIX you
don't actually waste any diskspace because you can symlink them
together.

So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's "best practice" on windows in
this area.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's "best practice" on windows in
this area.

When removing the application (in this case: pgsql), you'd remove that
old lib as well if it's the only app using it. If you have another
application installed, the deinstaller should observe this, and keep the
version.

I'm voting +1 for lib name versions.

Regards,
Andreas

-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: 19 December 2005 12:07
To: Martijn van Oosterhout; Dave Page
Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
pgsql-hackers@postgresql.org; Andreas Pflug
Subject: RE: [HACKERS] [pgadmin-hackers] Client-side password
encryption

Yes.
If FooApp is compiled against 8.0, it will then be unable to
run if you
upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
version if it's just a minor version upgrade (correct me if
I'm wrong).
On windows, it will break with an ugly dialog box. Which is why DLL
renames are usually only done for backwards incompatible changes.

So each app ships with it's required version of libpq, thus preventing
any issues, including problems caused by finding an older dll with a
different API.

Regards, Dave.

Yes.
If FooApp is compiled against 8.0, it will then be unable to run if
you upgrade libpq to 8.1. IIRC on Unix it will "fall

forward" to the

new version if it's just a minor version upgrade (correct me if I'm
wrong).
On windows, it will break with an ugly dialog box. Which is why DLL
renames are usually only done for backwards incompatible changes.

So each app ships with it's required version of libpq, thus
preventing any issues, including problems caused by finding
an older dll with a different API.

It makes life easier for us. Only then we can be almost certain that all
apps will ship with 8.0.0, 8.1.0 etc, and nobody will get any minor
version upgrades.

But yeah, the easiest for us is certainly to push that out to the app
vendor. Not really a problem for me, just wanted to point out the
scenario.

//Magnus

-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: 19 December 2005 14:50
To: Dave Page; Martijn van Oosterhout
Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
pgsql-hackers@postgresql.org; Andreas Pflug
Subject: RE: [HACKERS] [pgadmin-hackers] Client-side password
encryption

Yes.
If FooApp is compiled against 8.0, it will then be unable

to run if

you upgrade libpq to 8.1. IIRC on Unix it will "fall

forward" to the

new version if it's just a minor version upgrade (correct

me if I'm

wrong).
On windows, it will break with an ugly dialog box. Which

is why DLL

renames are usually only done for backwards incompatible changes.

So each app ships with it's required version of libpq, thus
preventing any issues, including problems caused by finding
an older dll with a different API.

It makes life easier for us. Only then we can be almost
certain that all
apps will ship with 8.0.0, 8.1.0 etc, and nobody will get any minor
version upgrades.

Why? I'm not advocating that the dll name change with revisions, only
major or minor version changes or if the API changes (which should never
happen from revision to revision (yes, I know...)), depending on which
numbering scheme is used.

Regards, Dave

Martijn van Oosterhout <kleptog@svana.org> writes:

Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...

Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new function will fail if used with old
library) for a guaranteed-to-break risk (*every* app fails if used
with *any* library version other than what it was built against).

The Unix version of the idea is considerably more flexible than
what would happen on Windows.

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 19 December 2005 15:00
To: Martijn van Oosterhout
Cc: Dave Page; Christopher Kings-Lynne; Peter Eisentraut;
pgsql-hackers@postgresql.org; Andreas Pflug
Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
encryption

Martijn van Oosterhout <kleptog@svana.org> writes:

Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...

Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new function will fail if used with old
library) for a guaranteed-to-break risk (*every* app fails if used
with *any* library version other than what it was built against).

If it's changed to include the so version, or PG version in the filename
(eg. Libpq41.dll, or libpq82.dll) then all we require is that a vendor
ship the appropriate version with his app. If it installs in a shared
location, it's guaranteed to only be upgraded by a point release because
the windows installers have no convention for including version numbers
in the filenames and will only upgrade a file of the name name, and with
an older version number (from the version resource).

Regards, Dave.