Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted

[Tino Wildenhain]

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@wildenhain.de>

[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.

--

[Tino Wildenhain]

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@wildenhain.de>

[Michael Samuel]

On Thu, 21 Apr 2005 11:32 pm, Rod Taylor wrote:
> On Thu, 2005-04-21 at 11:06 +0200, Tino Wildenhain wrote:
>
> One advantage of a random salt would be that the username can be changed
> without having to reset the password at the same time.

And the main advantage is that if you have an account with the same username
on another database server, it makes attacks twice as hard. (Assuming those
two database servers, or their backups are compromised)

Note that salts aren't supposed to be secret (well, no more so than the
password hash), they just need to be unique.

Of course, if you're going to add a salt (which requires changing the protocol
and the storage format), you may aswell move away from md5 (which has been
considered deprecated for quite some time... longer than it's been used in
PostgreSQL), and move towards something more secure, such as blowfish crypt
(or an AES adaptation of it?).

[Antoine Martin]

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@snowman.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?