Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
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.
On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
Eh? Just because you know everything the postmaster does doesn't mean you
can't be stopped. In the traditional unix password file scheme the crypt
string is public knowledge but it's not enough to log in. You need the
original
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Fri, Dec 23, 2005 at 09:12:52AM -0500, Greg Stark wrote:
Eh? Just because you know everything the postmaster does doesn't mean you
can't be stopped. In the traditional unix password file scheme the crypt
string is public knowledge but
On 23 Dec 2005 09:12:52 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
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'
On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
This isn't the first time this has been explained, but:
With password encryption you essentially have two options:
- Server knows password, use challenge-response
* Martijn van Oosterhout (kleptog@svana.org) wrote:
On Fri, Dec 23, 2005 at 09:42:44AM -0500, Stephen Frost wrote:
* Martijn van Oosterhout (kleptog@svana.org) wrote:
This isn't the first time this has been explained, but:
With password encryption you essentially have two options:
Stephen Frost wrote:
Is it actually doing challenge-response where the challenge is different
each time?
The docs say:
AuthenticationMD5Password
The frontend must now send a PasswordMessage containing the password
encrypted via MD5, using the 4-character salt specified in the
There's also Kerberos, which I'm happy to say seems to be
getting more and more use. I'd really like to get ODBC
Kerberos working, at least with MIT kerberos and then maybe
someday (if I can manage to get it
working...) setup some cross-realm stuff with the Windows AD and SSPI
(iirc)
] [pgadmin-hackers] Client-side password encryption
There's also Kerberos, which I'm happy to say seems to be getting more
and more use. I'd really like to get ODBC Kerberos working, at least
with MIT kerberos and then maybe someday (if I can manage to get it
working...) setup some cross-realm
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
ODBC and Kerberos works just fine, if you use the 8.1 ODBC driver. I use
it all the time :)
That's what I had heard, I just havn't gotten it working yet myself. :)
Believe me when I say that I *really* want to have it working though;
this
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] 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
Andrew Dunstan [EMAIL PROTECTED] 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
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
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
Christopher Kings-Lynne [EMAIL PROTECTED] 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,
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
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
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.
If you know the md5 hash, you know
Andreas Pflug wrote:
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
On 12/21/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Andreas Pflug wrote:
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
On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote:
If you add a version number to the Win32 libpq name, you have to update
any command-line compile tools that mention libpq after an upgrade. The
Unix linker knows about version numbers, but the Win32 linker doesn't,
so adding
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 ...
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Wed, Dec 21, 2005 at 02:51:46PM -0500, Bruce Momjian wrote:
If you add a version number to the Win32 libpq name, you have to update
any command-line compile tools that mention libpq after an upgrade. The
Unix linker knows
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: 20 December 2005 01:33
To: Dave Page
Cc: Tom Lane; Peter Eisentraut; pgsql-hackers@postgresql.org;
Andreas Pflug
Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
encryption
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
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
On Mon, Dec 19, 2005 at 08:51:23AM -, 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
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
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
On Mon, Dec 19, 2005 at 09:16:19AM -, 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
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
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
On Mon, Dec 19, 2005 at 10:32:03AM -, 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
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
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
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
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
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
] 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
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
] 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
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
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
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
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
Tom Lane wrote:
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
-Lynne
Cc: Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas
Pflug; Dave Page
Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
encryption
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
So it appears that pg_md5_encrypt is not officially
exported from libpq.
Does
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
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
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
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
Christopher Kings-Lynne [EMAIL PROTECTED] 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
46 matches
Mail list logo
