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

> The salt isn't always known... I don't know how an=20
> unprivledged user on a system w/ /etc/shadow could get at it=20
> anyway. I'm sure alot of people would be very anxious to=20
> know if you know of a way to do that...

The salt is known, just not by an unpriveledged user. But if you can =
access
/etc/shadow, then you know the salt and the hashed passwords.=20

The salt is added (dunno where in the original string) to the password =
prior
to hashing. Then the salt is prepended to the hased value and stored
somewhere, in your case, /etc/shadow.=20

For a salt to be usable, you have to know what it is. Secure hashes are =
"one
way" which means that you shouldn't be able to derive the original text
solely from the hash value. To create password: create 2 byte salt from
ASCII -> prepend salt to password -> hash salt+password with MD5 -> =
prepend
salt to hash value -> store it. To check password: get username and =
password
-> lookup hash string using username from /etc/shadow -> get salt from =
hash
value -> hash salt+password with MD5 -> compare value computed hash =
value
from stored hash value -> If match, user authenticated, if not, user not
authenticated.

So if you hash a password with a salt, and then lose the salt, you can =
never
check the password again. You have to know salt.=20

Since the salt is known, it has no effect on the "keyspace" because you
don't have to guess it. If there was no salt, then pre-computing a
dictionary is a much smaller task.=20

mike

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.

Circa 2005-04-21 dixit Mike Fratto:

:
: > I thought the idea of the salt was to aid in expanding the
: > keyspace. Even though the salt is known (in traditional Unix
: > passwd/shadow/master.passwd databases,
:
: I am pretty sure the intent the salt is to make pre-computation of a
: dictionaries infeasable due to storage requirements. It doesn't really add
: to the keyspace because the salt is known and doesn't have to be guessed.

.... which is exactly what i was speaking of. The salt increases the
keyspace for the precomputed table of password hashes. The conversation
was not about brute force attacks....

--
jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 809F:09B9:9686:D035:4AB0::9455:124B:0A62:DD6A:76D6 )
.................................................. ...................
:"The methods now being used to merchandise the political candidate :
: as though he were a deodorant positively guarantee the electorate :
: against ever hearing the truth about anything." --Aldous Huxley :
:................................................. ..................:

--QBJnsLb0QyYEYRYK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Mike Fratto (mfratto@nwc.com) wrote:
> Since the salt is known, it has no effect on the "keyspace" because you
> don't have to guess it. If there was no salt, then pre-computing a
> dictionary is a much smaller task.=20

That's the whole point of the discussion- the way Postgres's pg_shadow
stuff works the salt is known and *because* of that it might as well not
exist since it means that you can pre-compute the keyspace. Knowing the
salt means you can pre-compute the keyspace ahead of time. If you don't
know the salt until you've gained access then you'll have to wait till
then to begin computing the keyspace.

I suppose technically you could start pre-computing the keyspace before
then, but then it's a much larger keyspace which makes it much more
difficult.

Stephen

--QBJnsLb0QyYEYRYK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCaBxCrzgMPqB3kigRAlR6AJ4jUIxdf3kw3gaGQZtcFI/51Z1gmgCfcLOZ
j6vHFtu3RIihYAkBKro3j5k=
=x7r/
-----END PGP SIGNATURE-----

--QBJnsLb0QyYEYRYK--