Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords

Greetings,

There appears to be some deficiencies in both the documentation of the
'md5' authentication methology (in pg_hba.conf) and in the md5 hash
generation which is stored in pg_shadow.

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). This would allow for the pregeneration of the entire md5
keyspace using that 'salt' and then quick breakage of the hash once
it's retrieved by the attacker. Were a decent random salt of some
size used it would be difficult to guess and pregenerate the keyspace
for. Thus, keyspace generation would have to happen after pg_shadow
was compramised, giving the admin time to detect the compramise and
take corrective action.

A larger issue, which plays into the pg_shadow storage issue somewhat,
is the lack of proper documentation of the 'md5' method of
authentication available via pg_hba.conf. When using the 'md5' method
in pg_hba.conf this is what happens:

server sends a randomly generated 'seed' to the client
client performs md5(md5(password+username)+salt) using the salt from
the server and information provided by the user and sends the result
to the server
server performs md5(hash+salt) using the salt it sent to the client
and the hash which is stored in pg_shadow.

In so doing the server has effectively made the hash which is stored
in pg_shadow the key for authentication- the user's password is no
longer necessary to authenticate to the database, only the hash from
pg_shadow is required. It is not clear in the documentation that
using 'md5' in pg_hba.conf defeats 'with encrypted password' and the
hashing in pg_shadow. It is also not made clear that if you are
already handling transport-level security via SSL and/or IPSEC that
using md5 actually reduces security by not adding anything to the
transport-level security and defeating the on-disk security
effectivness of using md5 for pg_shadow.

It is true that while Postgres continues to use a known salt for hash
generation the effectiveness of md5 hashes in pg_shadow is reduced,
though not entirely defeated as not all have resources to generate
the keyspace for a username with a decent password (as the 'postgres'
superuser should have) or to generate the keyspace for any number of
user accounts which are the targetted accounts.

If password-based authentication is required (and other methods such
as Kerberos are unavailable), then, personally I would:

Discourage the use of 'md5' in pg_hba.conf and favor 'password'
Use good transport-level security via SSL and/or IPSEC
Change the hashing for what goes into pg_shadow to use a randomly
generated salt instead of the username (this would require
changing the protocol to allow for that randomly generated salt
to be provided to the client when 'md5' is being used in
pg_hba.conf); an alternative might be to use PAM in the meantime
Update the documetation accordingly to be clear on the issues
As soon as possible provide other hash algorithms such as sha1/2

I discussed this issue on IRC w/ some folks already though generally
they didn't appear to share my level of concern over this. My
biggest concern is that using 'md5' in pg_hba.conf reduces security
when another transport-level security mechanism is in place by a
significant amount, in my view, and this isn't clear in the
documentation.

Thanks for you time, happy to answer any questions/comments on my
analysis.

Stephen

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(at)roaringpenguin(dot)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(at)snowman(dot)net> writes:
> 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).

So?

The fact that we encrypt the contents of pg_shadow at all is not to
provide security against breakins by people who have managed to
obtain the contents of pg_shadow. Any such attacker knows as much as
the postmaster does, and so there isn't anything much the postmaster can
do to prevent a breakin. The reason we do it is to prevent such a
person (or a dishonest DBA) from obtaining the user's actual original
password. This doesn't improve the security of the database at all,
of course, but it does improve security globally if the user used the
same password for other systems.

> This would allow for the pregeneration of the entire md5
> keyspace using that 'salt' and then quick breakage of the hash once
> it's retrieved by the attacker.

Considering the size of the possible keyspace, this is pretty silly.

> Were a decent random salt of some
> size used it would be difficult to guess and pregenerate the keyspace
> for. Thus, keyspace generation would have to happen after pg_shadow
> was compramised, giving the admin time to detect the compramise and
> take corrective action.

Another large assumption: that the admin knows about the compromise
before the results are used.

>. It is also not made clear that if you are
> already handling transport-level security via SSL and/or IPSEC that
> using md5 actually reduces security by not adding anything to the
> transport-level security and defeating the on-disk security
> effectivness of using md5 for pg_shadow.

That's simply false. The contents of pg_shadow are never sent over the
wire.

You're going to have to work a lot harder to convince us there's any
significant issue here.

regards, tom lane

Stephen Frost <sfrost(at)snowman(dot)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

On Wed, Apr 20, 2005 at 05:03:18PM -0400, Tom Lane wrote:
> > This would allow for the pregeneration of the entire md5
> > keyspace using that 'salt' and then quick breakage of the hash once
> > it's retrieved by the attacker.
>
> Considering the size of the possible keyspace, this is pretty silly.

Actually, it's not as silly as you think. You can download rainbow
tables for Windows/LanMan passwords up to 14 or 15 characters in length.
Given the password hash and some code, you can determine the user's
password in a matter of minutes.

Simply put, MD5 is no longer strong enough for protecting secrets. It's
just too easy to brute-force. SHA1 is ok for now, but it's days are
numbered as well. I think it would be good to alter SHA1 (or something
stronger) as an alternative to MD5, and I see no reason not to use a
random salt instead of username.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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(at)decibel(dot)org> writes:
> Simply put, MD5 is no longer strong enough for protecting secrets. It's
> just too easy to brute-force. SHA1 is ok for now, but it's days are
> numbered as well. I think it would be good to alter SHA1 (or something
> stronger) as an alternative to MD5, and I see no reason not to use a
> random salt instead of username.

Well, I have no particular problem with offering SHA1 as an alternative
hash method for those who find MD5 too weak ... but I still question the
value of putting any random salt in the table. AFAICS you would have to
send that salt as part of the initial password challenge, which means
any potential attacker could find it out even before trying to
compromise pg_shadow; so Stephen's argument that there is a useful
improvement in protection against precomputation of password hashes
still falls down.

BTW, one could also ask exactly what threat model Stephen is concerned
about. ISTM anyone who can obtain the contents of pg_shadow has
*already* broken your database security.

regards, tom lane

On Wed, Apr 20, 2005 at 06:03:18PM -0400, Tom Lane wrote:
> Well, I have no particular problem with offering SHA1 as an alternative
> hash method for those who find MD5 too weak ... but I still question the
> value of putting any random salt in the table. AFAICS you would have to
> send that salt as part of the initial password challenge, which means
> any potential attacker could find it out even before trying to
> compromise pg_shadow; so Stephen's argument that there is a useful
> improvement in protection against precomputation of password hashes
> still falls down.
>
> BTW, one could also ask exactly what threat model Stephen is concerned
> about. ISTM anyone who can obtain the contents of pg_shadow has
> *already* broken your database security.

FWIW, I do think there's some benefit to not being able to pre-compute
an entire hash table for accounts such as 'postgres' and 'www'. But I
agree it would be useful to know the actual threat model.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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?"

Tom Lane wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or something
> > stronger) as an alternative to MD5, and I see no reason not to use a
> > random salt instead of username.
>
> Well, I have no particular problem with offering SHA1 as an alternative
> hash method for those who find MD5 too weak ... but I still question the
> value of putting any random salt in the table. AFAICS you would have to
> send that salt as part of the initial password challenge, which means
> any potential attacker could find it out even before trying to
> compromise pg_shadow; so Stephen's argument that there is a useful
> improvement in protection against precomputation of password hashes
> still falls down.
>
> BTW, one could also ask exactly what threat model Stephen is concerned
> about. ISTM anyone who can obtain the contents of pg_shadow has
> *already* broken your database security.

That's what I told him. I think his concern about pre-computed hashes
is the only real issue, and give 'postgres' is usually the super-user, I
can see someone pre-computing md5 postgres hashes and doing quick
comparisons, perhaps as a root kit so you don't have to do the hashing
yourself. I personally don't find that very compelling either.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> That's what I told him. I think his concern about pre-computed hashes
> is the only real issue, and give 'postgres' is usually the super-user, I
> can see someone pre-computing md5 postgres hashes and doing quick
> comparisons, perhaps as a root kit so you don't have to do the hashing
> yourself. I personally don't find that very compelling either.

Lessee ... we'll include a complete password hash table in a root kit,
which will be used at a point where we've already managed to read
pg_shadow but are somehow still lacking the ability to do anything else
we could want to the database ... nope, not very compelling.

regards, tom lane

Bruce Momjian wrote:

>>BTW, one could also ask exactly what threat model Stephen is concerned
>>about. ISTM anyone who can obtain the contents of pg_shadow has
>>*already* broken your database security.

> That's what I told him. I think his concern about pre-computed hashes
> is the only real issue, and give 'postgres' is usually the super-user, I
> can see someone pre-computing md5 postgres hashes and doing quick
> comparisons, perhaps as a root kit so you don't have to do the hashing
> yourself. I personally don't find that very compelling either.

The issue is that you should try your best to prevent dictionary attacks,
because often people use the same passwords for different things.
I know they shouldn't, but sometimes they do, so any measures you can
take to make a dictionary attack harder are worth doing, especially
when the random salt is so simple to implement.

--
David.

Tom Lane wrote:

>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
>
>>That's what I told him. I think his concern about pre-computed hashes
>>is the only real issue, and give 'postgres' is usually the super-user, I
>>can see someone pre-computing md5 postgres hashes and doing quick
>>comparisons, perhaps as a root kit so you don't have to do the hashing
>>yourself. I personally don't find that very compelling either.
>>
>>
>
>Lessee ... we'll include a complete password hash table in a root kit,
>which will be used at a point where we've already managed to read
>pg_shadow but are somehow still lacking the ability to do anything else
>we could want to the database ... nope, not very compelling.
>
>
>
>
[bugtraq removed - I don't think this belongs there, at least at this stage]

/etc/shadow is supposedly only readable by root (or things that are
setuid root). If you have root you already own the box. Yet we store
passwords there hashed with random salt.

My understanding is that Stephen would like a system where clear
passwords are never stored. He's right in saying that our "encrypted"
passwords are in effect cleartext, as a malicious client would only ever
need to know the hashed pw to gain access, and not the original
cleartext. Of course, adding random salt won't change that, and you are
quite right in saying that the random salt would have to be sent as part
of the challenge.

There's a choice between protecting the password over the wire via a
challenge/response system, and protecting it in storage. Postgres has
quite reasonably chosen the former. Stephen says "Well, I can protect
the wire comms via ssh or IPSEC, and I'd like storage protection too."
That also seems reasonable, although I don't think the sky is really
falling in.

Lastly, I have seen Jan say several times (on IRC) that mission-critical
DBs should not be exposed to untrusted networks, but always protected by
appropriate middleware. I could not agree more.

cheers

andrew

Tom Lane wrote:

> Lessee ... we'll include a complete password hash table in a root kit,
> which will be used at a point where we've already managed to read
> pg_shadow but are somehow still lacking the ability to do anything else
> we could want to the database ... nope, not very compelling.

You are correct that the threat against the PostgreSQL installation itself
is not very compelling. However, take a look at the bigger picture:
People crack into systems and then try to use those systems to crack
into other systems. If you can make it harder to recover passwords
in the PostgreSQL system, then you've made it harder for attackers
to use those recovered passwords to attack other systems.

Think of the complete security environment, not just the security
of a particular PostgreSQL installation. Having random salts makes
it much harder for attackers to answer questions like "Does user X
have the same password in PostgreSQL installation 1 as he does in PostgreSQL
installation 2".

Regards,

David.

* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> Stephen Frost <sfrost(at)snowman(dot)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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > 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).
>
> So?
>
> The fact that we encrypt the contents of pg_shadow at all is not to
> provide security against breakins by people who have managed to
> obtain the contents of pg_shadow. Any such attacker knows as much as
> the postmaster does, and so there isn't anything much the postmaster can
> do to prevent a breakin. The reason we do it is to prevent such a
> person (or a dishonest DBA) from obtaining the user's actual original
> password. This doesn't improve the security of the database at all,
> of course, but it does improve security globally if the user used the
> same password for other systems.

A dishonest DBA would have no trouble obtaining the user's actual
original password regardless through any number of means, both technical
and social. I can go into them if you'd like but the first one would
probably be just change pg_hba.conf to say 'password' instead of 'md5'
and you're basically done.

Additionally, a dishonest DBA has no need for the original password if
the user has the same username on multiple postgres databases (not
exactly unlikely) and those postgres systems use 'md5' in pg_hba.conf.
This is because when using the 'md5' mechanism in pg_hba.conf the
original password is irrelevant, all that matters is the
password+username hash, which is exactly what's stored in pg_shadow.

Were other systems such as ssh to use this same mechanism then again for
those you would not need the original password but only the hash in
order to authenticate yourself. Thus, claiming that you're protecting
the user from a dishonest DBA is, imv, at best a false sense of
security.

> > This would allow for the pregeneration of the entire md5
> > keyspace using that 'salt' and then quick breakage of the hash once
> > it's retrieved by the attacker.
>
> Considering the size of the possible keyspace, this is pretty silly.

Not as silly as I wish it was. :/

> > Were a decent random salt of some
> > size used it would be difficult to guess and pregenerate the keyspace
> > for. Thus, keyspace generation would have to happen after pg_shadow
> > was compramised, giving the admin time to detect the compramise and
> > take corrective action.
>
> Another large assumption: that the admin knows about the compromise
> before the results are used.

It would be nice to give the admin some time to detect the compromise.
If a known salt is used then the admin gets essentially no time. If a
random salt is used then the admin will have at least some time while
the attacker generates the keyspace to find a cleartext version to pass
to the server- provided the server is using 'password' and *not* 'md5'
in pg_hba.conf. If the server is using 'md5' in pg_hba.conf then all is
lost as soon as pg_shadow is compromised.

> >. It is also not made clear that if you are
> > already handling transport-level security via SSL and/or IPSEC that
> > using md5 actually reduces security by not adding anything to the
> > transport-level security and defeating the on-disk security
> > effectivness of using md5 for pg_shadow.
>
> That's simply false. The contents of pg_shadow are never sent over the
> wire.

I didn't mean to suggest that they were. However, if you use 'md5' in
pg_hba.conf then what is stored in pg_shadow might as well be the
original password since it is all that is required to authenticate.
Sure, technically you also need the salt from the server for the
transport-md5-hash, but the server gives that to you and then all you
have to do is a simple md5hash.

> You're going to have to work a lot harder to convince us there's any
> significant issue here.

Happy to do my best. Hope this helps some. I strongly feel that using
'md5' in pg_hba.conf when using SSL or IPSEC should be strongly
discouraged. It adds nothing in that case and does some harm in the
event pg_shadow is compromised (through stealing of a backup tape, or a
partial compromise of the system whereby an attacker is able to gain
privledged access to read part of a file or similar).

Thanks,

Stephen

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or something
> > stronger) as an alternative to MD5, and I see no reason not to use a
> > random salt instead of username.
>
> Well, I have no particular problem with offering SHA1 as an alternative
> hash method for those who find MD5 too weak ... but I still question the

SHA2 would also be nice.

> value of putting any random salt in the table. AFAICS you would have to
> send that salt as part of the initial password challenge, which means
> any potential attacker could find it out even before trying to
> compromise pg_shadow; so Stephen's argument that there is a useful
> improvement in protection against precomputation of password hashes
> still falls down.

Only if you're using 'md5' in pg_hba.conf. In that case, yes, you would
have to send the salt as part of the password challenge. Personally, I
would discourage use of 'md5' in pg_hba.conf because of this and because
it changes the authentication token from the password to the hash which
is what is directly stored in the database.

> BTW, one could also ask exactly what threat model Stephen is concerned
> about. ISTM anyone who can obtain the contents of pg_shadow has
> *already* broken your database security.

Just because they have access to pg_shadow does not necessairly mean
they have access to the database files directly or are able to write to
anything (such as to destroy data). It's possible they pulled
pg_shadow off a backup tape and are bent on destroying all the data in
your live database, and not in just reading it, or if your data is very
time sensitive then they want a more recent version for its value, etc.

There are other possibilities but my concern centers around a partial
system compromise where pg_shadow is obtained by the attacker, yes.

Thanks,

Stephen

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> [bugtraq removed - I don't think this belongs there, at least at this stage]

Sure.

> /etc/shadow is supposedly only readable by root (or things that are
> setuid root). If you have root you already own the box. Yet we store
> passwords there hashed with random salt.

Right, exactly.

> My understanding is that Stephen would like a system where clear
> passwords are never stored. He's right in saying that our "encrypted"
> passwords are in effect cleartext, as a malicious client would only ever
> need to know the hashed pw to gain access, and not the original
> cleartext. Of course, adding random salt won't change that, and you are
> quite right in saying that the random salt would have to be sent as part
> of the challenge.

No, adding a random salt wouldn't change that, that's a direct flaw of
the 'md5' mechanism in pg_hba.conf. However, I can choose not to use
the 'md5' mechanism in pg_hba.conf and can use 'password' instead.
There's not currently an option to say "use a random salt instead of the
username as the salt" for those of us concerned both about people
sniffing the wire and compromising pg_shadow.

> There's a choice between protecting the password over the wire via a
> challenge/response system, and protecting it in storage. Postgres has
> quite reasonably chosen the former. Stephen says "Well, I can protect
> the wire comms via ssh or IPSEC, and I'd like storage protection too."
> That also seems reasonable, although I don't think the sky is really
> falling in.

Right.

> Lastly, I have seen Jan say several times (on IRC) that mission-critical
> DBs should not be exposed to untrusted networks, but always protected by
> appropriate middleware. I could not agree more.

I agree with this also, of course, but there's only so much one can
do and security in layers...

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(at)shentel(dot)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(at)mit(dot)edu) wrote:
> > Stephen Frost <sfrost(at)snowman(dot)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(at)decibel(dot)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(at)decibel(dot)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(at)decibel(dot)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

Am Mittwoch, den 20.04.2005, 16:23 -0500 schrieb Jim C. Nasby:
> On Wed, Apr 20, 2005 at 05:03:18PM -0400, Tom Lane wrote:
...
> Simply put, MD5 is no longer strong enough for protecting secrets. It's
> just too easy to brute-force. SHA1 is ok for now, but it's days are
> numbered as well. I think it would be good to alter SHA1 (or something
> stronger) as an alternative to MD5, and I see no reason not to use a
> random salt instead of username.

I wonder where you want to store that random salt and how this would add
to the security.

--
Tino Wildenhain <tino(at)wildenhain(dot)de>

On Thu, 2005-04-21 at 11:06 +0200, Tino Wildenhain wrote:
> Am Mittwoch, den 20.04.2005, 16:23 -0500 schrieb Jim C. Nasby:
> > On Wed, Apr 20, 2005 at 05:03:18PM -0400, Tom Lane wrote:
> ...
> > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > numbered as well. I think it would be good to alter SHA1 (or something
> > stronger) as an alternative to MD5, and I see no reason not to use a
> > random salt instead of username.
>
> I wonder where you want to store that random salt and how this would add
> to the security.

One advantage of a random salt would be that the username can be changed
without having to reset the password at the same time.

--

Am Donnerstag, den 21.04.2005, 09:32 -0400 schrieb Rod Taylor:
> On Thu, 2005-04-21 at 11:06 +0200, Tino Wildenhain wrote:
> > Am Mittwoch, den 20.04.2005, 16:23 -0500 schrieb Jim C. Nasby:
> > > On Wed, Apr 20, 2005 at 05:03:18PM -0400, Tom Lane wrote:
> > ...
> > > Simply put, MD5 is no longer strong enough for protecting secrets. It's
> > > just too easy to brute-force. SHA1 is ok for now, but it's days are
> > > numbered as well. I think it would be good to alter SHA1 (or something
> > > stronger) as an alternative to MD5, and I see no reason not to use a
> > > random salt instead of username.
> >
> > I wonder where you want to store that random salt and how this would add
> > to the security.
>
> One advantage of a random salt would be that the username can be changed
> without having to reset the password at the same time.

Still this does not answer the question where that salt is to be
stored :)

(instead of username one could use somefacyhash(userid) to be
independend from username - otoh, if you change usernames
you usually face some other serious problems like object
ownership and friends)
--
Tino Wildenhain <tino(at)wildenhain(dot)de>

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(at)decibel(dot)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(at)dunslane(dot)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(at)snowman(dot)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

> Simply put, MD5 is no longer strong enough for protecting secrets. It's
> just too easy to brute-force. SHA1 is ok for now, but it's days are
> numbered as well. I think it would be good to alter SHA1 (or something
> stronger) as an alternative to MD5, and I see no reason not to use a
> random salt instead of username.

If you aren't paying close enough attention to your database server to
see that someone is trying to brute force your MD5 password you have
bigger problems.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)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

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> >Simply put, MD5 is no longer strong enough for protecting secrets. It's
> >just too easy to brute-force. SHA1 is ok for now, but it's days are
> >numbered as well. I think it would be good to alter SHA1 (or something
> >stronger) as an alternative to MD5, and I see no reason not to use a
> >random salt instead of username.
>
> If you aren't paying close enough attention to your database server to
> see that someone is trying to brute force your MD5 password you have
> bigger problems.

If the attacker knows the salt then she can do almost all of the
brute-force work up-front before even attempting to attack the system
directly. The sys admin would have no way of knowing this was
happening. Once this is done the attacker just needs the hash from
pg_shadow to quickly find the user's password (or something that hashes
to the same thing).

In this situation I'm assuming the system is using the 'password'
method in pg_hba.conf. If the system used the 'md5' method in
pg_hba.conf the attacker would need only the hash from pg_shadow to
authenticate and wouldn't need the users original password at all.

If a random salt were used in this situation, and 'password' were used
in pg_hba.conf then the attacker would be unable to determine the salt
ahead of time and would be forced to generate the keyspace after
obtaining pg_shadow to brute-force the password, a time consuming
process hopefully given the admin an opportunity to discover the
compromise.

Thanks,

Stephen

Stephen Frost wrote:

>* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>
>
>>Stephen Frost <sfrost(at)snowman(dot)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(at)snowman(dot)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(at)dunslane(dot)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(at)mit(dot)edu) wrote:
> Stephen Frost <sfrost(at)snowman(dot)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

Joshua D. Drake wrote:
>> Simply put, MD5 is no longer strong enough for protecting secrets. It's
>> just too easy to brute-force. SHA1 is ok for now, but it's days are
>> numbered as well. I think it would be good to alter SHA1 (or something
>> stronger) as an alternative to MD5, and I see no reason not to use a
>> random salt instead of username.
>
>
> If you aren't paying close enough attention to your database server to
> see that someone is trying to brute force your MD5 password you have
> bigger problems.

The comments on md5 and sha1 are both inaccurate if you're comparing
them. Encrypted passwords are as strong as the design of the password.
In some cases, SHA-1 is a faster brute force because SHA-1 is a faster
hash. There are two issues here. Using SHA-1 to hash a password, and the
strength of a password. If the implementation of SHA-1 is not effective,
there could be weaknesses that enable reducing the time required to
perform exhaustive/dictionary attacks against sha-1 protected password.

I'm out of context, but I had to make some corrections.

--
Best Regards,
Lance James
Secure Science Corporation
www.securescience.com
Author of 'Phishing Exposed'
http://www.securescience.net/amazon/
Have Phishers stolen your customers' logins? Find out with DIA
https://slam.securescience.com/signup.cgi - it's free!

Stephen Frost wrote:
-- Start of PGP signed section.
> * Andrew Dunstan (andrew(at)dunslane(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, Apr 20, 2005 at 22:27:01 -0400,
Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> SHA2 would also be nice.

I think the new hash functions are called SHA256 and SHA512.
For Postgres' purposes the recent weaknesses found in SHA1 and MD5
aren't a big deal.

* Bruno Wolff III (bruno(at)wolff(dot)to) wrote:
> On Wed, Apr 20, 2005 at 22:27:01 -0400,
> Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > SHA2 would also be nice.
>
> I think the new hash functions are called SHA256 and SHA512.
> For Postgres' purposes the recent weaknesses found in SHA1 and MD5
> aren't a big deal.

Well, alright, SHA256 and SHA512. It would be nice to have Postgres
support them.

Stephen

Tom Lane wrote:

>Paul Tillotson <pntil(at)shentel(dot)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(at)shentel(dot)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(at)shentel(dot)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(at)mac(dot)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

On Thu, 2005-04-21 at 17:27 -0500, Bruno Wolff III wrote:
> On Wed, Apr 20, 2005 at 22:27:01 -0400,
> Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >
> > SHA2 would also be nice.
>
> I think the new hash functions are called SHA256 and SHA512.
> For Postgres' purposes the recent weaknesses found in SHA1 and MD5
> aren't a big deal.
It is irrelevant here, if I am reading this correctly:
http://theory.csail.mit.edu/~yiqun/shanote.pdf
"collision search attacks"
Basically, multiple input data that have the same output hash, which is
of no use when what you are trying to find is the input.
Finding collisions quicker for a known input is one thing, but that is
not going to reduce the search space, not even your storage space (it is
unlikely that the colliding results would all be valid input).

Is adding the non-guessable salt that hard anyway?

* Antoine Martin (antoine(at)nagafix(dot)co(dot)uk) wrote:
> Basically, multiple input data that have the same output hash, which is
> of no use when what you are trying to find is the input.
> Finding collisions quicker for a known input is one thing, but that is
> not going to reduce the search space, not even your storage space (it is
> unlikely that the colliding results would all be valid input).

Erm, you aren't necessairly trying to find the input... It may be the
case that you're trying to find what you need to authenticate to this
server, or any other PostgreSQL server where the same userid & input are
used. In that case you just need something that hashes to the same
thing. Using a random salt would mean that it's different per server so
breaking it on one doesn't help you against another server unless you
happened to find the actual original input.

> Is adding the non-guessable salt that hard anyway?

It is if you want to continue to support the 'md5' method in pg_hba.conf
because the wireline protocol will probably need to change. A less
intrusive alternative would be to add an 'with encrypted password 'xyz'
with random salt' or some such which would only be supported with the
'password' method in pg_hba.conf.

One problem with this is that you then can't just switch from password
to md5 or back again. Perhaps that's ok though? Comments?

Stephen

On Sat, 2005-04-23 at 09:02 -0400, Stephen Frost wrote:
> * Antoine Martin (antoine(at)nagafix(dot)co(dot)uk) wrote:
> > Basically, multiple input data that have the same output hash, which is
> > of no use when what you are trying to find is the input.
> > Finding collisions quicker for a known input is one thing, but that is
> > not going to reduce the search space, not even your storage space (it is
> > unlikely that the colliding results would all be valid input).
>
> Erm, you aren't necessairly trying to find the input... It may be the
> case that you're trying to find what you need to authenticate to this
> server, or any other PostgreSQL server where the same userid & input are
> used. In that case you just need something that hashes to the same
> thing.
Agreed, what I said was that it is highly unlikely you will find
colliding inputs that are valid, so the "SHA weakness" does not really
help you here as it does not reduce the search space:
You are much better off pre-calculating hashes for possible usernames &
passwords than working backwards and generating all possible hashes
hoping that one would happen to be matching a real entry...
Usernames are not exactly random, passwords are less predictable, the
chance of a useful collision on the username+password is remote at best.
> Using a random salt would mean that it's different per server so
> breaking it on one doesn't help you against another server unless you
> happened to find the actual original input.
Absolutely.
>
> > Is adding the non-guessable salt that hard anyway?
>
> It is if you want to continue to support the 'md5' method in pg_hba.conf
> because the wireline protocol will probably need to change. A less
> intrusive alternative would be to add an 'with encrypted password 'xyz'
> with random salt' or some such which would only be supported with the
> 'password' method in pg_hba.conf.
>
> One problem with this is that you then can't just switch from password
> to md5 or back again. Perhaps that's ok though? Comments?
Just add another authentication method - call it 'md5-salt' (sharing
most of the 'md5' code), you get backwards compatibility and you advise
users to migrate to the new salt hash. Shouldn't be too hard...
Might as well do a 'sha512-salt' too.

Antoine