Обсуждение: Re: [pgadmin-hackers] Client-side password encryption
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 likechar *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
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
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
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
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
isused.
-N
--unencrypted Does not encrypt the user's password stored in the database. If not specified, the default password
behavioris 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
>>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
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
>>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
Christopher Kings-Lynne <chriskl@familyhealth.com.au> 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 everything the postmaster does, so
it's hard to see where such an attacker is going to be stopped. The
entire point here is not to expose the cleartext password, and that
really has nothing to do with whether you're going to break into the
PG database. It's about protecting users who are foolish enough to
use the same cleartext password for multiple services.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Christopher Kings-Lynne <chriskl@familyhealth.com.au> 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 everything the postmaster does, so > it's hard to see where such an attacker is going to be stopped. 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 password that crypts to that value. > The entire point here is not to expose the cleartext password, and that > really has nothing to do with whether you're going to break into the PG > database. It's about protecting users who are foolish enough to use the same > cleartext password for multiple services. Well that's a fine goal but it's not as good as an authentication scheme that doesn't store a password equivalent in the database. -- greg
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 password that crypts to that value. 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 authentication so password is not visible on wire. - Server only knows hash of password, password must be sent in clear over wire. These exist in the real world as PAP or CHAP, but there are many other examples. The reason it works in UNIX login is that the "in-the-clear" transit of the password is from the keyboard, via the kernel to a single process, not over a network, so it is considered secure. The login protocol for SMB has a similar flaw. If you can read the password file on an SMB server, you can login as any user. You may have to hack a client to make it work, but it is possible. PostgreSQL uses a variation where the cleartext password sent is just the md5 hash of the real password. It just stops the admin guessing it to see if the user is using it elsewhere. You really don't need the original password to login, just the hash. The solution is obvious, public-key authentication which doesn't have these problems. eg SSH, SSL, etc... Or a trusted third party (ident). 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.
* 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 it's not enough to log in. You need the
> > original password that crypts to that value.
>
> 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 authentication so
> password is not visible on wire.
> - Server only knows hash of password, password must be sent in clear
> over wire.
Erm, Postgres isn't doing either of these...? You even talk about what
Postgres does below so I'm kind of bemused that you don't mention it in
your list... :)
> These exist in the real world as PAP or CHAP, but there are many other
> examples. The reason it works in UNIX login is that the "in-the-clear"
> transit of the password is from the keyboard, via the kernel to a
> single process, not over a network, so it is considered secure. The
> login protocol for SMB has a similar flaw. If you can read the password
> file on an SMB server, you can login as any user. You may have to hack
> a client to make it work, but it is possible.
Well, and these days quite often the network connection is encrypted.
> PostgreSQL uses a variation where the cleartext password sent is just
> the md5 hash of the real password. It just stops the admin guessing it
> to see if the user is using it elsewhere. You really don't need the
> original password to login, just the hash.
Stops the admin from guessing the password, but makes the text on the
disk *the* authentication token, meaning someone who manages to get a
copy of the password file gets full access to the system.
> The solution is obvious, public-key authentication which doesn't have
> these problems. eg SSH, SSL, etc... Or a trusted third party (ident).
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) things and have ODBC use that to authenticate against my
Linux-based PostgreSQL server.
I guess to do that we'd have to make libpq under Windows have the option
of using the Windows SSPI layer. Anyone looked into this at all?
Anyone know if it'd have a chance of getting accepted?
Thanks,
Stephen
On 23 Dec 2005 09:12:52 -0500, Greg Stark <gsstark@mit.edu> wrote: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > Christopher Kings-Lynne <chriskl@familyhealth.com.au> 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 everything the postmaster does, so > > it's hard to see where such an attacker is going to be stopped. > > 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 password that crypts to that value. In unix scheme the cleartext password is send over wire and server stores hash. So indeed even if you know the hash, it wont get you in. But current postgres case the md5 is sent over wire and also stored in server. So knowing md5 is enough to get in. The md5 is only used to obfuscate the cleartext password from administrators, in case the user uses it somewhere else too. (And the reason for current md5 hacking is to avoid the cleartext password from appearing from logs, thus overall rounding the goal.) > > The entire point here is not to expose the cleartext password, and that > > really has nothing to do with whether you're going to break into the PG > > database. It's about protecting users who are foolish enough to use the same > > cleartext password for multiple services. > > Well that's a fine goal but it's not as good as an authentication scheme that > doesn't store a password equivalent in the database. http://srp.stanford.edu/whatisit.html -- marko
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 authentication so > > password is not visible on wire. > > - Server only knows hash of password, password must be sent in clear > > over wire. > > Erm, Postgres isn't doing either of these...? You even talk about what > Postgres does below so I'm kind of bemused that you don't mention it in > your list... :) Postgres *is* using one of these, the first one, where the server knows the authentication token (the md5 hash of the password). UNIX login uses the latter. Perhaps if you substitute "authentication token" for "password" above it makes it clearer? > Well, and these days quite often the network connection is encrypted. If you use SSL or SSH? Sure. I think in that case you can setup pg_hba.conf to require "password" in which case the server will only accept an unhashed password. > Stops the admin from guessing the password, but makes the text on the > disk *the* authentication token, meaning someone who manages to get a > copy of the password file gets full access to the system. If md5 auth is setup, yes. > 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) things and have ODBC use that to authenticate against my > Linux-based PostgreSQL server. Yeah, I was counting kerberos under "trust a third party". It shouldn't be too hard to add other such systems, like PAM has been... 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.
* 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:
> > >
> > > - Server knows password, use challenge-response authentication so
> > > password is not visible on wire.
> > > - Server only knows hash of password, password must be sent in clear
> > > over wire.
> >
> > Erm, Postgres isn't doing either of these...? You even talk about what
> > Postgres does below so I'm kind of bemused that you don't mention it in
> > your list... :)
>
> Postgres *is* using one of these, the first one, where the server knows
> the authentication token (the md5 hash of the password). UNIX login
> uses the latter. Perhaps if you substitute "authentication token" for
> "password" above it makes it clearer?
Is it actually doing challenge-response where the challenge is different
each time? I thought it just used the user's username or some such.
Point being- can an attacker use what's passed around on the network to
authenticate to the system directly? If it's a random
challenge/response setup then they shouldn't be able to unless they
manage to convince the server to give it the same challenge (which
should be very difficult).
> > Well, and these days quite often the network connection is encrypted.
>
> If you use SSL or SSH? Sure. I think in that case you can setup
> pg_hba.conf to require "password" in which case the server will only
> accept an unhashed password.
Yeah, but you can't do both, which is the real annoyence. You can't get
it to do the same as unix-based auth.
> > Stops the admin from guessing the password, but makes the text on the
> > disk *the* authentication token, meaning someone who manages to get a
> > copy of the password file gets full access to the system.
>
> If md5 auth is setup, yes.
Yeah, but the other alternative is clear-text passwords on the disk, not
something I really care for either, honestly.
> > 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) things and have ODBC use that to authenticate against my
> > Linux-based PostgreSQL server.
>
> Yeah, I was counting kerberos under "trust a third party". It shouldn't
> be too hard to add other such systems, like PAM has been...
I don't know that I'd consider PAM under Postgres as really being PAM.
It's *only* password-checking, and there's the issue that Postgres
doesn't have a root process to do the PAM work under so the postgres
user has to be in shadow (which means all the Postgres processes can
read /etc/shadow, not exactly a nice setup) to have PAM work. Perhaps
SASL and saslauthd could be an option for Postgres. I'm not sure though
as I don't think the Postgres protocol currently supports the kind of
back-and-forth that both PAM and SASL want to be able to do for things
like password-expring, forced-password-changes, etc.
Thanks,
Stephen
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 specifiedin the AuthenticationMD5Password message. If this is the correct password, the server responds with an AuthenticationOk,otherwise it responds with an ErrorResponse. A little investigation reveals that this is port->md5salt which is 4 random bytes set up fresh per connection (see src/backend/libpq/auth.c and src/backend/postmaster/postmaster.c). So it seems indeed to be a true (small) one time challenge token, unless I've missed something. cheers andrew