On Sat, 2005-04-23 at 09:02 -0400, Stephen Frost wrote:
> * Antoine Martin ([EMAIL PROTECTED]) 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 thin
* Kevin Brown ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > Unfortunately, Postgres doesn't currently encrypt pg_shadow and even if
> > it did you'd have to have the password stored on disk somewhere in the
> > clear if you wanted the database to start automatically, which is more
> > impo
* Antoine Martin ([EMAIL PROTECTED]) 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
Stephen Frost wrote:
> Unfortunately, Postgres doesn't currently encrypt pg_shadow and even if
> it did you'd have to have the password stored on disk somewhere in the
> clear if you wanted the database to start automatically, which is more
> important if you havn't got backup databases and whatno
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 us
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > With the 'md5' method the server will send will send a randomly
> > generated salt to the client which will then concatenate the user's name
> > to the password, perform an md5 on that result, then concatenate t
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 <[EMAIL PROTECTED]> wrote:
> >
> > SHA2 would also be nice.
>
> I think the new hash functions are called SHA256 and SHA512.
> For Postgres' purposes the recent weaknesses found i
* Eliot Simcoe ([EMAIL PROTECTED]) 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 someth
On Apr 21, 2005, at 8:59 PM, Stephen Frost wrote:
* Paul Tillotson ([EMAIL PROTECTED]) 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 fir
Greg Stark wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>
> > With the 'md5' method the server will send will send a randomly
> > generated salt to the client which will then concatenate the user's name
> > to the password, perform an md5 on that result, then concatenate the
> > result of th
Stephen Frost <[EMAIL PROTECTED]> writes:
> With the 'md5' method the server will send will send a randomly
> generated salt to the client which will then concatenate the user's name
> to the password, perform an md5 on that result, then concatenate the
> result of the md5 to the salt provided by
* Paul Tillotson ([EMAIL PROTECTED]) 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 u
Tom Lane wrote:
Paul Tillotson <[EMAIL PROTECTED]> 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
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> > > I think the behaviour on the wire should be more explcitly stated.
> >
> > Please comment on the message I just sent to -hackers which has
Stephen Frost wrote:
-- Start of PGP signed section.
> * Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> > I think the behaviour on the wire should be more explcitly stated.
>
> Please comment on the message I just sent to -hackers which has a much
> longer and more detailed explanation of what happen
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> I think the behaviour on the wire should be more explcitly stated.
Please comment on the message I just sent to -hackers which has a much
longer and more detailed explanation of what happens.
Thanks,
Stephen
signature.asc
De
I think the behaviour on the wire should be more explcitly stated.
cheers
andrew
Bruce Momjian wrote:
Index: doc/src/sgml/client-auth.sgml
===
RCS file: /cvsroot/
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
> On Wed, Apr 20, 2005 at 22:27:01 -0400,
> Stephen Frost <[EMAIL PROTECTED]> 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
> a
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> With the documentation text clarified, this patch fixes the actual
> documentation problem that both 'password' and 'md5' supporte encrypted
> pg_shadow passwords, while only crypt does not. Applied to 8.0.X and
> HEAD.
Great, thanks. Here's a su
Stephen Frost wrote:
-- Start of PGP signed section.
> * Andrew Dunstan ([EMAIL PROTECTED]) 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
pgman wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Andrew Dunstan ([EMAIL PROTECTED]) 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 assert
On Wed, Apr 20, 2005 at 22:27:01 -0400,
Stephen Frost <[EMAIL PROTECTED]> 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.
---(end of br
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> 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 sourc
Josh Berkus wrote:
> > I've already offered elsewhere to work on
> > writing a random-salt patch for PostgreSQL targeted at 8.1 and this
> > encourages me further. I understand that I'd need to be sure it was
> > backwards compatible to some extent (do both older client <-> newer
> > server and n
Josh,
* Josh Berkus (josh@agliodbs.com) wrote:
> Actually, I think older client <-> newer server is the least critical. We'd
> be incrementing libpq for this. Right, Bruce?
I'm not 100% sure that libpq's API/ABI would need to change for this,
which is what would cause an SONAME change. This
* Andrew Dunstan ([EMAIL PROTECTED]) 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
Stephen,
> I'm concerned about both using a random salt in pg_shadow and about
> better documentation about what happens when you use 'md5' in
> pg_hba.conf.
Yep, per our conversation on IRC. Frankly, I responded on Bugtraq mainly to
the other person's comment that we'd been ignoring the issue
Stephen Frost <[EMAIL PROTECTED]> 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 se
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost <[EMAIL PROTECTED]> 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.
* Josh Berkus (josh@agliodbs.com) wrote:
> David, Stephen,
[Changed back to pgsql-hackers]
> Well, from our perspective, a random salt only protects against a very narrow
> range of attack types -- ones in which the attacker already has access to the
> physical database and wants to reverse-eng
* Joshua D. Drake ([EMAIL PROTECTED]) 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
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> 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 stil
Joshua Drake wrote:
> 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.
Everybody is completely missing the point. :-(
The point of a random salt is *NOT* to increase the security of y
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
Stephen Frost <[EMAIL PROTECTED]> 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
* Andrew Dunstan ([EMAIL PROTECTED]) 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 challeng
"Jim C. Nasby" <[EMAIL PROTECTED]> 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
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
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 st
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
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
"Jim C. Nasby" <[EMAIL PROTECTED]> 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
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 la
On Wed, Apr 20, 2005 at 09:58:31PM -0400, Stephen Frost wrote:
> * Greg Stark ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> 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 disc
Paul Tillotson <[EMAIL PROTECTED]> 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
[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 a
* Andrew Dunstan ([EMAIL PROTECTED]) 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
* Tom Lane ([EMAIL PROTECTED]) wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> 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 som
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> 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' sup
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> 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 m
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
Tom Lane wrote:
Bruce Momjian 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'
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
Bruce Momjian 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
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> 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) a
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
"Jim C. Nasby" <[EMAIL PROTECTED]> 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, a
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
Stephen Frost <[EMAIL PROTECTED]> 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 en
Stephen Frost <[EMAIL PROTECTED]> 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
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 inste
* David F. Skoll ([EMAIL PROTECTED]) 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
> > ac
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 Augu
63 matches
Mail list logo
