Thread: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Stephen Frost wrote: > The md5 hash which is generated for and stored in pg_shadow does not > use a random salt but instead uses the username which can generally be > determined ahead of time (especially for the 'postgres' superuser > account). I noted that this was a problem back in August, 2002: http://archives.postgresql.org/pgsql-admin/2002-08/msg00253.php Then, as now, the developers weren't very concerned. Regards, David.
* David F. Skoll (dfs@roaringpenguin.com) wrote: > Stephen Frost wrote: > > The md5 hash which is generated for and stored in pg_shadow does not > > use a random salt but instead uses the username which can generally be > > determined ahead of time (especially for the 'postgres' superuser > > account). > > I noted that this was a problem back in August, 2002: > > http://archives.postgresql.org/pgsql-admin/2002-08/msg00253.php > > Then, as now, the developers weren't very concerned. I have some hopes that pointing out the rather large problem with the md5 authentication mechanism in pg_hba.conf will lead them to discourage it's use and thus reduce the occourances of the salt being made available to the user giving more weight to the usefullness of having it be a random salt. Additionally, it's been a few years, perhaps viewpoints have changed. Stephen
Stephen Frost <sfrost@snowman.net> writes: > I have some hopes that pointing out the rather large problem with the > md5 authentication mechanism in pg_hba.conf will lead them to discourage > it's use and thus reduce the occourances of the salt being made > available to the user giving more weight to the usefullness of having it > be a random salt. Additionally, it's been a few years, perhaps > viewpoints have changed. Salts are always given to the user, that's how they work. They're not secret. The issue pointed out back then was that lots of hosts would have usernames with the same name, namely "postgres". So a distributed attack would be able to use a dictionary attack if it were targeting just the "postgres" user on many hosts. That was deemed not a threat model worth worrying about. It's pretty unlikely someone would have access to the md5sums for many different hosts. -- greg
* Greg Stark (gsstark@mit.edu) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > I have some hopes that pointing out the rather large problem with the > > md5 authentication mechanism in pg_hba.conf will lead them to discourage > > it's use and thus reduce the occourances of the salt being made > > available to the user giving more weight to the usefullness of having it > > be a random salt. Additionally, it's been a few years, perhaps > > viewpoints have changed. > > Salts are always given to the user, that's how they work. They're not secret. You're confusing the issues I'm afraid. If you're using md5 to secure your transport then yes, you must provide the salt to the user since the same salt must be used on both sides. That's not the salt under discussion, however; the salt I'm referring to is the one which is used to make it difficult to brute-force the password from a copy of the resultant hash. That salt is not given to anyone because no one else needs it- only the server needs to know that salt so that it can add it to the password to compare against the hash in the database. > The issue pointed out back then was that lots of hosts would have usernames > with the same name, namely "postgres". So a distributed attack would be able > to use a dictionary attack if it were targeting just the "postgres" user on > many hosts. > > That was deemed not a threat model worth worrying about. It's pretty unlikely > someone would have access to the md5sums for many different hosts. I'm worried about them having access to the md5sums for my host.. If they did and I used 'md5' in pg_hba.conf they wouldn't need to brute force anything, they'd have all they needed to connect as the postgres users on my database. Stephen
[snip] >>The issue pointed out back then was that lots of hosts would have usernames >>with the same name, namely "postgres". So a distributed attack would be able >>to use a dictionary attack if it were targeting just the "postgres" user on >>many hosts. >> >>That was deemed not a threat model worth worrying about. It's pretty unlikely >>someone would have access to the md5sums for many different hosts. >> >> > >I'm worried about them having access to the md5sums for my host.. >If they did and I used 'md5' in pg_hba.conf they wouldn't need to brute >force anything, they'd have all they needed to connect as the postgres >users on my database. > > > Lest anyone think that this is a theoretical attack, PHPBB suffered an SQL injection last year that allowed to you to, in essence, learn the truth or falsity of a boolean condition (nothing more) because you could add conditions to the WHERE clause. If the application is connecting to the database as superuser, then the complete password can be read by testing each letter of the hash using substring and subselects in an expression. For example, (SELECT substring(password, 1, 1) = 'F' FROM pg_shadow WHERE user='postgres') tests if the first character of the password hash is an F. By doing this, then the attacker can learn any user's password, even though he can't perform any inserts, updates, deletes, etc., and he can only extract data slowly.* Of course, someone is asking to be 0wn3d if they set up PHPBB to connect as superuser. However, given the amount of work done to prevent foot-shooting in other areas (e.g., server refuses to run as root), it seems inconsistent that using md5 as the connection method opens the server to any attacker who knows the hashes. Perhaps for 8.1 a new authentication method, say, "securemd5," ought to be created in which remedies this deficiency? Regards, Paul Tillotson *Interesting mental exercise: if all that your SQL injection allows is to add conditions to a WHERE clause evaluated as superuser, how does one execute arbitrary code? I can't think of how to do it offhand. - You can't INSERT, UPDATE, DELETE, or perform any DDL (including creating new functions) - You can't use COPY to overwrite local files. - There aren't any built-in functions that write files, change tables, etc., are there? Wouldn't you have to go for a buffer overflow in one of the built-in functions? That's considerably more difficult than simply connecting as superuser and using COPY to overwrite local files with arbitrary data.
Paul Tillotson <pntil@shentel.net> writes: > Of course, someone is asking to be 0wn3d if they set up PHPBB to connect > as superuser. However, given the amount of work done to prevent > foot-shooting in other areas (e.g., server refuses to run as root), it > seems inconsistent that using md5 as the connection method opens the > server to any attacker who knows the hashes. Hm? Using md5 is certainly not any *more* dangerous than any of the other possible password-based methods. > *Interesting mental exercise: if all that your SQL injection allows is > to add conditions to a WHERE clause evaluated as superuser, how does one > execute arbitrary code? I can't think of how to do it offhand. If I found the correct reference: http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=185180 then this wasn't any more circumscribed than any other SQL injection attack. Consider injecting something like ... AND FALSE; CREATE USER trojan WITH PASSWORD 'trivial'; SELECT ... repeat original query text ... It's worth pointing out also that adding a per-user-entry random salt to the password protocol is not some kind of penalty-free magic bullet. In particular it implies information leakage: I can tell from the password challenge (or lack of one) whether the username I have offered is valid. So rather than claiming "this is unconditionally a good thing to do", you must actually provide a credible scenario that makes the threat you are defending against more dangerous than the sorts of new threats we'll be exposed to. So far I haven't seen a very credible threat here. regards, tom lane
On Wed, Apr 20, 2005 at 09:58:31PM -0400, Stephen Frost wrote: > * Greg Stark (gsstark@mit.edu) wrote: > > Stephen Frost <sfrost@snowman.net> writes: > > > I have some hopes that pointing out the rather large problem with the > > > md5 authentication mechanism in pg_hba.conf will lead them to discourage > > > it's use and thus reduce the occourances of the salt being made > > > available to the user giving more weight to the usefullness of having it > > > be a random salt. Additionally, it's been a few years, perhaps > > > viewpoints have changed. > > > > Salts are always given to the user, that's how they work. They're not secret. > > You're confusing the issues I'm afraid. If you're using md5 to secure > your transport then yes, you must provide the salt to the user since the > same salt must be used on both sides. That's not the salt under > discussion, however; the salt I'm referring to is the one which is used > to make it difficult to brute-force the password from a copy of the > resultant hash. That salt is not given to anyone because no one else > needs it- only the server needs to know that salt so that it can add it > to the password to compare against the hash in the database. Something that just occured to me... if you're using a random salt, you can change it periodically without any disruption. So in the case of a site that's worried about brute-forcing a password or hash you can periodically update all the salts with new random values. The protocol could also send a nonce as part of the key exchange. I believe both techniques would add security. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
On Thu, Apr 21, 2005 at 12:13:50AM -0400, Tom Lane wrote: > It's worth pointing out also that adding a per-user-entry random salt > to the password protocol is not some kind of penalty-free magic bullet. > In particular it implies information leakage: I can tell from the > password challenge (or lack of one) whether the username I have offered > is valid. So rather than claiming "this is unconditionally a good thing > to do", you must actually provide a credible scenario that makes the > threat you are defending against more dangerous than the sorts of new > threats we'll be exposed to. So far I haven't seen a very credible > threat here. I would think it wouldn't be hard to change the protocol/code so that the response from providing an invalid user is the same as providing a valid one. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
"Jim C. Nasby" <decibel@decibel.org> writes:
> I would think it wouldn't be hard to change the protocol/code so that
> the response from providing an invalid user is the same as providing a
> valid one.
How would you do that? The response for a valid user will (a) include
the same salt on repeated trials (so no generating a random one); (b)
usually be different from the salt given for other usernames (so no
using the same one every time, either) and (c) probably be provided in a
measurably different time from the time taken by any algorithm that
manages to work around (a) and (b).
You could maybe work around (c) by delaying *all* password challenges to
take, say, 100 msec ... but that's hardly what I call a cost-free
solution either.
regards, tom lane
Tom Lane wrote: >It's worth pointing out also that adding a per-user-entry random salt >to the password protocol is not some kind of penalty-free magic bullet. >In particular it implies information leakage: I can tell from the >password challenge (or lack of one) whether the username I have offered >is valid. So rather than claiming "this is unconditionally a good thing >to do", you must actually provide a credible scenario that makes the >threat you are defending against more dangerous than the sorts of new >threats we'll be exposed to. So far I haven't seen a very credible >threat here. > > > > Ok, this made me think a bit. It's a valid point. I started off just thinking that you would send along the stored salt with the random session salt in something like the current AuthenticationMD5Password message, and if the user didn't exist send something faked out. But you would still get the information leak unless the faked out part could be consistent (inconsistency would imply an invalid user id), so it couldn't just be something random - you'd either have to make it algorithmic, which would kinda defeat the purpose, or keep a dictionary ... and we're back in much the same place we came in. cheers andrew
"Jim C. Nasby" <decibel@decibel.org> writes:
> Something that just occured to me... if you're using a random salt, you
> can change it periodically without any disruption. So in the case of a
> site that's worried about brute-forcing a password or hash you can
> periodically update all the salts with new random values.
Not unless you force the users to change passwords. How are you going
to use MD5(passwd,oldsalt) to derive MD5(passwd,newsalt) when you don't
know passwd?
regards, tom lane
* Andrew Dunstan (andrew@dunslane.net) wrote:
> Tom Lane wrote:
> >It's worth pointing out also that adding a per-user-entry random salt
> >to the password protocol is not some kind of penalty-free magic bullet.
> >In particular it implies information leakage: I can tell from the
> >password challenge (or lack of one) whether the username I have offered
> >is valid. So rather than claiming "this is unconditionally a good thing
> >to do", you must actually provide a credible scenario that makes the
> >threat you are defending against more dangerous than the sorts of new
> >threats we'll be exposed to. So far I haven't seen a very credible
> >threat here.
>
> Ok, this made me think a bit. It's a valid point. I started off just
> thinking that you would send along the stored salt with the random
> session salt in something like the current AuthenticationMD5Password
> message, and if the user didn't exist send something faked out. But you
> would still get the information leak unless the faked out part could be
> consistent (inconsistency would imply an invalid user id), so it
> couldn't just be something random - you'd either have to make it
> algorithmic, which would kinda defeat the purpose, or keep a dictionary
> ... and we're back in much the same place we came in.
Can't keep a dictionary, of course. The algorithmic approach would
probably work- md5(username+pgsalt) where pgsalt is a random
per-installation salt, perhaps changed periodically, a random point once
a week or similar. The result of that md5 would then be truncated or
similar to provide the 'fake' salt to the client. md5's are pretty
cheap, I don't know that you could tell the difference between an md5
and a disk access (if it's not cache'd for whatever reason), esp. over a
network.
Changing the pgsalt shouldn't actually be a problem- that randomly
generated salt would change periodically anyway whenever a user changed
their password.
I'd also like to point out that this is *only* an issue for the 'md5'
authentication mechanism in pg_hba.conf, which I think should be
discouraged in favor of 'password' and SSL/IPSEC.
Thanks,
Stephen
Stephen Frost <sfrost@snowman.net> writes:
> I'd also like to point out that this is *only* an issue for the 'md5'
> authentication mechanism in pg_hba.conf, which I think should be=20
> discouraged in favor of 'password' and SSL/IPSEC.
This is still utter nonsense. How can md5 be less secure than storing
your password in the clear?
Whether you want the extra security of IPSEC is an orthogonal discussion
really; if your connection goes over an insecure network then you most
likely need it in order to hide your data, never mind your password.
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I'd also like to point out that this is *only* an issue for the 'md5'
> > authentication mechanism in pg_hba.conf, which I think should be=20
> > discouraged in favor of 'password' and SSL/IPSEC.
>
> This is still utter nonsense. How can md5 be less secure than storing
> your password in the clear?
I think you're mixing the issues. 'password' in pg_hba.conf does not
automatically imply 'without encrypted password'/plaintext in pg_shadow.
There are two seperate uses of md5 here and they counter each other.
If you use 'md5' in pg_hba.conf then using 'with encrypted password'/md5
in pg_shadow is pointless because the authentication token is the hash
which is stored in cleartext in pg_shadow. If you don't use 'with
encrypted password' in pg_shadow then you can't use 'md5' in pg_hba.conf
in the currently implementation- but there's no particular reason for
that to be the case, and that could be fixed.
If you use 'with encrypted password' and a random salt then you can't
use 'md5' in pg_hba.conf w/o sending the salt, which defeats the point
of it being random. It's an interesting interaction.
> Whether you want the extra security of IPSEC is an orthogonal discussion
> really; if your connection goes over an insecure network then you most
> likely need it in order to hide your data, never mind your password.
This statement actually argues to my point that the 'md5' *transport*
usage, using 'md5' in pg_hba.conf, should be discouraged, since it
doesn't protect the data. I do feel that we should use md5 for
pg_shadow. In using md5 in pg_shadow I feel we should use a random salt
that is not given out and is stored in pg_shadow. This is not a problem
if the 'password' *tranport* mechanism in pg_hba.conf is used since the
password is sent to the server by the client in the clear and is not
hashed at all- that is done on the server and must always be done by the
server for that mechanism.
Thanks,
Stephen
Stephen Frost wrote: >* Tom Lane (tgl@sss.pgh.pa.us) wrote: > > >>Stephen Frost <sfrost@snowman.net> writes: >> >> >>>I'd also like to point out that this is *only* an issue for the 'md5' >>>authentication mechanism in pg_hba.conf, which I think should be=20 >>>discouraged in favor of 'password' and SSL/IPSEC. >>> >>> >>This is still utter nonsense. How can md5 be less secure than storing >>your password in the clear? >> >> > >I think you're mixing the issues. 'password' in pg_hba.conf does not >automatically imply 'without encrypted password'/plaintext in pg_shadow. >There are two seperate uses of md5 here and they counter each other. > > > The docs say: "only md5 supports encrypted passwords stored in pg_shadow; the other two require unencrypted passwords to be stored there." So either your assertion that 'password' auth does not imply plaintext password storage is wrong, or the docs are. cheers andrew
Stephen Frost <sfrost@snowman.net> writes: > If you use 'md5' in pg_hba.conf then using 'with encrypted password'/md5 > in pg_shadow is pointless because the authentication token is the hash > which is stored in cleartext in pg_shadow. The source of my confusion earlier was that I assumed the server used MD5 hashes similarly to how Unix uses crypt hashes. It seems it's not, it's using MD5 hashes as password-equivalents. That's pretty silly. It means the original password isn't stored in the database which could help limit a compromise from escalating to other services that use the same password. But that's all it accomplishes. In the traditional way to use hashes in this circumstance the goal is to avoid storing a password-equivalent entirely. So the client would still send the original password, which would then be hashed and compared with the stored hash. In that plan leaking the hash isn't a security threat at all. You still have to provide the original password to log in, and you can't get that from the hash. The use of a salt is useful in that scenario because it prevents someone from being able to build a large dictionary of hashes in advance and look up the equivalent password quickly. If the hash is a password-equivalent then I don't see the point of salts in the first place. All it means is if someone *does* compromise your postgres server then they can use a dictionary attack to pull out the original password and attack other services. But they've already compromised your database, is that really your biggest worry at that point? Using the hash as a password-equivalent is a bad idea all around. -- greg
* Andrew Dunstan (andrew@dunslane.net) wrote:
> The docs say: "only md5 supports encrypted passwords stored in
> pg_shadow; the other two require unencrypted passwords to be stored
> there." So either your assertion that 'password' auth does not imply
> plaintext password storage is wrong, or the docs are.
The docs are wrong. Sorry, I knew that and forgot to mention it
explicitly previously. Using 'password' in pg_hba.conf while using
'with encrypted password'/md5 in pg_shadow works just fine.
Just tested here to make 100% sure, under 8.0.1.
Thanks,
Stephen
* Greg Stark (gsstark@mit.edu) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > If you use 'md5' in pg_hba.conf then using 'with encrypted password'/md5
> > in pg_shadow is pointless because the authentication token is the hash
> > which is stored in cleartext in pg_shadow.
>
> The source of my confusion earlier was that I assumed the server used MD5
> hashes similarly to how Unix uses crypt hashes. It seems it's not, it's using
> MD5 hashes as password-equivalents. That's pretty silly. It means the original
> password isn't stored in the database which could help limit a compromise from
> escalating to other services that use the same password. But that's all it
> accomplishes.
>
> In the traditional way to use hashes in this circumstance the goal is to avoid
> storing a password-equivalent entirely. So the client would still send the
> original password, which would then be hashed and compared with the stored
> hash.
Right, exactly, that can be done in Postgres, you just have to use
'password' in pg_hba.conf instead of 'md5'. Because of the goal of
supporting the 'md5' method though it apparently was decided that the
salt for pg_shadow would be the username instead of a random salt (since
that would then have to be given to the client).
> In that plan leaking the hash isn't a security threat at all. You still have
> to provide the original password to log in, and you can't get that from the
> hash.
>
> The use of a salt is useful in that scenario because it prevents someone from
> being able to build a large dictionary of hashes in advance and look up the
> equivalent password quickly.
Yes, exactly. :)
> If the hash is a password-equivalent then I don't see the point of salts in
> the first place. All it means is if someone *does* compromise your postgres
> server then they can use a dictionary attack to pull out the original password
> and attack other services. But they've already compromised your database, is
> that really your biggest worry at that point?
Well, my goal is to not make the hash password-equivalent by not using
the method which makes it that way- 'md5' in pg_hba.conf. Then it makes
sense to use a salt, etc.
> Using the hash as a password-equivalent is a bad idea all around.
I agree completely, and thus move to discourage the 'md5' transport
method in pg_hba.conf in favor of 'password' and SSL/IPSEC.
Thanks,
Stephen
Stephen Frost wrote: -- Start of PGP signed section. > * Andrew Dunstan (andrew@dunslane.net) wrote: > > The docs say: "only md5 supports encrypted passwords stored in > > pg_shadow; the other two require unencrypted passwords to be stored > > there." So either your assertion that 'password' auth does not imply > > plaintext password storage is wrong, or the docs are. > > The docs are wrong. Sorry, I knew that and forgot to mention it > explicitly previously. Using 'password' in pg_hba.conf while using > 'with encrypted password'/md5 in pg_shadow works just fine. > > Just tested here to make 100% sure, under 8.0.1. I see the documentation is slightly confusing. I have applied this patch to HEAD and 8.0.X to clarify it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/client-auth.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v retrieving revision 1.74 diff -c -c -r1.74 client-auth.sgml *** doc/src/sgml/client-auth.sgml 9 Apr 2005 03:52:43 -0000 1.74 --- doc/src/sgml/client-auth.sgml 21 Apr 2005 22:18:42 -0000 *************** *** 575,582 **** The password-based authentication methods are <literal>md5</>, <literal>crypt</>, and <literal>password</>. These methods operate similarly except for the way that the password is sent across the ! connection. But only <literal>md5</> supports encrypted ! passwords stored in <structname>pg_shadow</structname>; the other two require unencrypted passwords to be stored there. </para> --- 575,582 ---- The password-based authentication methods are <literal>md5</>, <literal>crypt</>, and <literal>password</>. These methods operate similarly except for the way that the password is sent across the ! connection. However, only <literal>md5</> allows encrypted ! passwords to be stored in <structname>pg_shadow</structname>; the other two require unencrypted passwords to be stored there. </para>
Tom Lane wrote: >Paul Tillotson <pntil@shentel.net> writes: > > >Hm? Using md5 is certainly not any *more* dangerous than any of the >other possible password-based methods. > > > Maybe I misunderstood, but I thought that others were saying that, if someone gets the contents of pg_shadow, then - if you use only "password" in your pg_hba.conf, he has to break one of the hashes first in order to log in. - but if you use "md5" in your pg_hba.conf, then he doesn't have to break the hashes at all. Is this correct? I guess I personally felt "betrayed" when I heard this since I (naively) assumed that the point of hashing passwords was to make it so that someone who is able to read your database is prevented from logging in and corrupting the data, installing root-kits, etc. Now I see that the point of md5 authenticate is to address an entirely different problem, namely, having the cleartext password being captured on the wire. Regards, Paul Tillotson
* Paul Tillotson (pntil@shentel.net) wrote:
> Maybe I misunderstood, but I thought that others were saying that, if
> someone gets the contents of pg_shadow, then
>
> - if you use only "password" in your pg_hba.conf, he has to break one of
> the hashes first in order to log in.
> - but if you use "md5" in your pg_hba.conf, then he doesn't have to
> break the hashes at all.
(in order to authenticate to your Postgres installation as a given user)
> Is this correct?
Yes, this is correct.
> I guess I personally felt "betrayed" when I heard this since I (naively)
Me too. :/
> assumed that the point of hashing passwords was to make it so that
> someone who is able to read your database is prevented from logging in
> and corrupting the data, installing root-kits, etc.
The hash in pg_shadow should only be visible to the database superuser,
or someone who has access to the unix account postgres runs as.
> Now I see that the point of md5 authenticate is to address an entirely
> different problem, namely, having the cleartext password being captured
> on the wire.
The intention of the 'md5' method in pg_hba.conf is to avoid having the
password go over the network in the clear, yes. Unfortunately, this
pretty much requires that the database have something which is
password-equivilant stored on disk.
Thanks,
Stephen
On Apr 21, 2005, at 8:59 PM, Stephen Frost wrote:
> * Paul Tillotson (pntil@shentel.net) wrote:
>
>> Maybe I misunderstood, but I thought that others were saying that, if
>> someone gets the contents of pg_shadow, then
>>
>> - if you use only "password" in your pg_hba.conf, he has to break
>> one of
>> the hashes first in order to log in.
>> - but if you use "md5" in your pg_hba.conf, then he doesn't have to
>> break the hashes at all.
>>
>
> (in order to authenticate to your Postgres installation as a given
> user)
>
>
>> Is this correct?
>>
>
> Yes, this is correct.
>
>
>> I guess I personally felt "betrayed" when I heard this since I
>> (naively)
>>
>
> Me too. :/
>
>
>> assumed that the point of hashing passwords was to make it so that
>> someone who is able to read your database is prevented from
>> logging in
>> and corrupting the data, installing root-kits, etc.
>>
>
> The hash in pg_shadow should only be visible to the database
> superuser,
> or someone who has access to the unix account postgres runs as.
>
>
>> Now I see that the point of md5 authenticate is to address an
>> entirely
>> different problem, namely, having the cleartext password being
>> captured
>> on the wire.
>>
>
> The intention of the 'md5' method in pg_hba.conf is to avoid having
> the
> password go over the network in the clear, yes. Unfortunately, this
> pretty much requires that the database have something which is
> password-equivilant stored on disk.
Wouldn't it be possible for postgres to rehash the md5 checksum of the
password before storing it in pg_shadow? This seems preferable if not
optimal.
Does anyone know why this is not being done?
>
> Thanks,
>
> Stephen
>
Thanks,
Eliot Simcoe
* Eliot Simcoe (esimcoe@mac.com) wrote: > On Apr 21, 2005, at 8:59 PM, Stephen Frost wrote: > >The intention of the 'md5' method in pg_hba.conf is to avoid having > >the > >password go over the network in the clear, yes. Unfortunately, this > >pretty much requires that the database have something which is > >password-equivilant stored on disk. > > Wouldn't it be possible for postgres to rehash the md5 checksum of the > password before storing it in pg_shadow? This seems preferable if not > optimal. > Does anyone know why this is not being done? Well, let's consider what's happening with that: server- user added 'with encrypted password' server- generate random salt server- perform md5(md5(password+username)+salt) into hash server- store hash and salt in pg_shadow client- contact server server- randomly generate challenge server- send challenge to client client- perform md5(md5(password+username)+challenge) into response client- send response to server server- retrive hash and salt from pg_shadow server- perform md5(hash+salt) into expected server- compare response from client to expected server- nope, they don't match... Whoops, that doesn't work, trying to compare: md5(md5(password+username)+challenge) to md5(md5(password+username)+salt) Challenge and salt aren't the same, nor should they be (if they were then they'd have to be constant and you would have to send it over the wire). If I missed something in this, please let me know. Stephen