Salt in encrypted password in pg_shadow

[David Garamond]

I read that the password hash in pg_shadow is salted with username. Is
this still the case? If so, since probably 99% of all PostgreSQL has
"postgres" as the superuser name, wouldn't it be better to use standard
Unix/Apache MD5 hash instead?

--
dave
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Tom Lane]

David Garamond <li***@zara.6.i sreserved.com> writes:

I read that the password hash in pg_shadow is salted with username. Is
this still the case? If so, since probably 99% of all PostgreSQL has
"postgres" as the superuser name, wouldn't it be better to use standard
Unix/Apache MD5 hash instead?

How does that improve anything? If we add a random salt into it, we'd
have to store the salt in pg_shadow, so there wouldn't be any secrecy
added --- an attacker who can read pg_shadow could see the salt too.

(Actually, an attacker who can read pg_shadow is already superuser,
so it's not clear there's anything left to hide from him anyway.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[David Garamond]

Tom Lane wrote:

I read that the password hash in pg_shadow is salted with username. Is
this still the case? If so, since probably 99% of all PostgreSQL has
"postgres" as the superuser name, wouldn't it be better to use standard
Unix/Apache MD5 hash instead?
How does that improve anything? If we add a random salt into it, we'd
have to store the salt in pg_shadow, so there wouldn't be any secrecy
added --- an attacker who can read pg_shadow could see the salt too.

Consider someone who creates a long list of:

MD5( "postgres" + "aaaaaaaa" )
MD5( "postgres" + "aaaaaaab" )
MD5( "postgres" + "aaaaaaac" )
...

Now if he has access to other people's pg_shadow, he can compare the
hashes with his dictionary. Replacing "postgres" with a random salt
defeats this dictionary attack (and thus he will have to resort to brute
force).
(Actually, an attacker who can read pg_shadow is already superuser,
so it's not clear there's anything left to hide from him anyway.)

But consider someone who finds a harddisk or tape containing a database
backup... he can then gain access to the real, online database.

--
dave
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Richard Huxton]

David Garamond wrote:

Consider someone who creates a long list of:

MD5( "postgres" + "aaaaaaaa" )
MD5( "postgres" + "aaaaaaab" )
MD5( "postgres" + "aaaaaaac" )
...

Now if he has access to other people's pg_shadow, he can compare the
hashes with his dictionary. Replacing "postgres" with a random salt
defeats this dictionary attack (and thus he will have to resort to brute
force).

But surely you have to store the random salt in pg_shadow too? Or am I
missing something?

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Richard Huxton <de*@archonet.c om> writes:

David Garamond wrote:

Consider someone who creates a long list of:
MD5( "postgres" + "aaaaaaaa" )
MD5( "postgres" + "aaaaaaab" )
MD5( "postgres" + "aaaaaaac" )

But surely you have to store the random salt in pg_shadow too? Or am I
missing something?

I think David is suggesting that the hypothetical attacker could gain
economies of scale in multiple attacks (ie, if he'd been able to steal
the contents of multiple installations' pg_shadow, he'd only need to
generate his long list of precalculated hashes once). I think this is
too far-fetched to justify an authentication protocol change though.

Also, MD5 hashing is fast enough that I'm not sure the above is really
significantly cheaper than a straight brute-force attack, ie, you just
take your list of possible passwords and compute the hashes on the fly.
The hashes are going to be much longer than the average real-world
password, so reading in a list of hashes is going to take several times
as much I/O as reading the passwords --- seems to me that it'd be
cheaper just to re-hash each password.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[David Garamond]

Tom Lane wrote:

I think David is suggesting that the hypothetical attacker could gain
economies of scale in multiple attacks (ie, if he'd been able to steal
the contents of multiple installations' pg_shadow, he'd only need to
generate his long list of precalculated hashes once). I think this is
too far-fetched to justify an authentication protocol change though.

Also, MD5 hashing is fast enough that I'm not sure the above is really
significantly cheaper than a straight brute-force attack, ie, you just
take your list of possible passwords and compute the hashes on the fly.
The hashes are going to be much longer than the average real-world
password, so reading in a list of hashes is going to take several times
as much I/O as reading the passwords --- seems to me that it'd be
cheaper just to re-hash each password.

Many people use short and easy-to-guess passwords (remember we're not
talking about the superuser only here), so the dictionary attack can be
more effective than people think. And considering many people use the
same password for several things, Postgres could become one of the easy
sources to get/guess people's plaintext passwords from hacked machines.

At least Apache and Unix have been random-salting passwords for a while now.

However, I realize this will break the current MD5 hash, probably too
painful to do at the moment. Perhaps for the future, non-MD5 hash...

--
dave

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Tom Lane]

David Garamond <li***@zara.6.i sreserved.com> writes:

Tom Lane wrote:

Also, MD5 hashing is fast enough that I'm not sure the above is really
significantly cheaper than a straight brute-force attack, ie, you just
take your list of possible passwords and compute the hashes on the fly.
The hashes are going to be much longer than the average real-world
password, so reading in a list of hashes is going to take several times
as much I/O as reading the passwords --- seems to me that it'd be
cheaper just to re-hash each password.

Many people use short and easy-to-guess passwords (remember we're not
talking about the superuser only here), so the dictionary attack can be
more effective than people think.

And that responds to the speed argument how? I quite agree that a
guessable password is risky, but putting in a random salt offers no
real advantage if the salt has to be stored in the same place as the
encrypted password.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Steve Atkins]

On Tue, Sep 07, 2004 at 03:09:28PM -0400, Tom Lane wrote:

David Garamond <li***@zara.6.i sreserved.com> writes:

Tom Lane wrote:

Also, MD5 hashing is fast enough that I'm not sure the above is really
significantly cheaper than a straight brute-force attack, ie, you just
take your list of possible passwords and compute the hashes on the fly.
The hashes are going to be much longer than the average real-world
password, so reading in a list of hashes is going to take several times
as much I/O as reading the passwords --- seems to me that it'd be
cheaper just to re-hash each password.

Many people use short and easy-to-guess passwords (remember we're not
talking about the superuser only here), so the dictionary attack can be
more effective than people think.

And that responds to the speed argument how? I quite agree that a
guessable password is risky, but putting in a random salt offers no
real advantage if the salt has to be stored in the same place as the
encrypted password.

The usual attack against hashed passwords is to use a dictionary
driven password generator to create a large number of passwords, find
the hash of each of those, then store the passwords on disk indexed by
the hash.

That's a one-time effort that can then be used in the future to crack
any number of password hashes extremely cheaply - given any hash you
can find the corresponding password, if you have one, with one index
lookup.

A random salt stored with the hashed password increases the storage
and precomputation time required by the size of the salt (so a 16 bit
salt would increase the storage and precomputation time needed by
a factor of 65536). That increase makes the pre-computed dictionary
attack pretty much infeasible.

Cheers,
Steve

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[David Garamond]

Tom Lane wrote:

Many people use short and easy-to-guess passwords (remember we're not
talking about the superuser only here), so the dictionary attack can be
more effective than people think.

And that responds to the speed argument how? I quite agree that a
guessable password is risky, but putting in a random salt offers no
real advantage if the salt has to be stored in the same place as the
encrypted password.

Hm, I thought the purpose of salt is generally well understood? A
well-known string such as "postgres" is *not* a good salt at all.

Here's a couple of pages that hopefully can explain better:

http://en.wikipedia.org/wiki/Dictionary_attack
http://en.wikipedia.org/wiki/Salt_(cryptography)

--
dave

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

Steve Atkins <st***@blighty. com> writes:

A random salt stored with the hashed password increases the storage
and precomputation time required by the size of the salt (so a 16 bit
salt would increase the storage and precomputation time needed by
a factor of 65536). That increase makes the pre-computed dictionary
attack pretty much infeasible.

[ raised eyebrow... ] It is not immediately obvious that a factor of
2^16 makes the difference between feasible and infeasible. As
counterexamples , if it would otherwise take you one microsecond to break
the password, 64 milliseconds isn't going to scare you; if it would
otherwise take you a century to break the password, raising it to
64k centuries isn't going to make for a very meaningful improvement in
security either.

Show me a scheme where the random salt isn't stored right beside the
password, and I might start to get interested.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster