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/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

> 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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Peter Eisentraut said:

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


Well, these changes have broken the windows build, so something needs to
change.I don't see a reason in principle not to expose our routine, given
that its name means it is unlikely to conflict with anything else.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:

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

Where are we on this? In general I agree with Tom, but I have no time to
do the work. Unless someone has an immediate implementation, I suggest
that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
which is the minimum needed to unbreak Windows builds, while this gets
sorted out properly.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Andrew Dunstan <andrew@dunslane.net> writes:
> Where are we on this? In general I agree with Tom, but I have no time to
> do the work. Unless someone has an immediate implementation, I suggest
> that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
> which is the minimum needed to unbreak Windows builds, while this gets
> sorted out properly.

I had forgotten that the Windows build is broken. I'll see what I can
do with throwing together the cleaner-API function.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

I wrote:
> I had forgotten that the Windows build is broken. I'll see what I can
> do with throwing together the cleaner-API function.

Done, but I noticed that the change to createuser has arguably broken
it; at least we need to change the docs. To wit, the docs say

-E
--encrypted
Encrypts the user's password stored in the database. If not
specified, the default password behavior is used.

-N
--unencrypted
Does not encrypt the user's password stored in the database. If not
specified, the default password behavior is used.

As currently coded, however, the behavior when neither switch is given
is to force the password to be encrypted --- the database's
password_encryption setting is overridden.

I'm not sure we can do much about this --- certainly we don't want the
default behavior of createuser to still be to send an unencrypted
password. But if we leave the code as-is the docs need a change.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

>>Where are we on this? In general I agree with Tom, but I have no time to
>>do the work. Unless someone has an immediate implementation, I suggest
>>that pro tem we add pg_md5_encrypt to src/interfaces/libpq/exports.txt,
>>which is the minimum needed to unbreak Windows builds, while this gets
>>sorted out properly.
>
>
> I had forgotten that the Windows build is broken. I'll see what I can
> do with throwing together the cleaner-API function.

Another question about these encrypted passwords. phpPgAdmin needs to
connect to databases that are sometimes on other servers.

I use the pg_connect() function to do this. This is passed down to
PQconenct() I presume.

So, can I specify the password to pg_connect() as
'md5127349123742342344234'?

ie. Can I CONNECT using an md5'd password?

Also, does this work for non-md5 host lines on the server, and how can I
avoid doing it on older (pre-7.2) PostgreSQL??

Chris


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> 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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match