Re: How passwords can be crypted in postgres?

On Thu, Jan 04, 2001 at 10:53:12PM -0500, some SMTP stream spewed forth:
> Gordan Bobic wrote:
> >
> > > Here's a crypted password: 00xNyXeahk4NU. I crypted it in perl as
> > > crypt(<guessme>, salt). So what is <guessme>?
> > >
> > > The point of a one way hash is that it's, well, one way. Pretty much
> > > the only way you're going to figure out what password that encrypted
> > > string corresponds to is to brute force it. Considering that I crypted
> > > a fairly long random string, that could take you a while. A really long
> > > while, unless you've got a budget orders of magnitude larger than most
> > > people.
> >
> > [snip]
> >
> > > Until the advent of shadow password files, which help defeat brute force
> > > attacks of the type I just mentioned, the /etc/password file has been
> > > readable by everyone. It really doesn't matter that much if people know
> > > the crypted string. They still won't be able to authenticate themselves
> > > until they know the real password.
> > >
> > > So the problem you're trying to defeat by crypting your passwords is the
> > > problem of someone reading your password file knowing all of your
> > > passwords.
> > >
> > > Now if you're dumb enough to send cleartext passwords unencrypted over a
> > > public network, you need some schooling. And of course any programs
> > > doing authentication need to be secure. But that's a different problem
> > > altogether.
> >
> > I was referring to a different aspect of security. I was referring to
> > preventing more of a "man-in-the-middle" type of attack. If you have a
> > packet sniffer somewhere between the client and the server, then someone
> > could read your packet containing the encrypted password and use it to
> > authenticate to the server, without knowing or caring what the real
> > password is. If you can send the encrypted password to the server that
> > matches, you're in.
>
> How so? The server is going to take the string you send it, and one-way
> hash it. If you send it the hash value, it will hash that. Unless that
> happens to hash to itself, which is exceedingly unlikely, you will not
> be authenticated.
>
> What kind of system are you talking about?

It seems to me that the situation he describes would be one in which
the frontend recieves an auth key ("password" or whatever) and then
compares the hash of it to a value in the database. A similar situation
would arise if the frontend merely passed the auth key to the database
and the database hashed it and compared the hash to a stored hash.

It is really just a big mess.
Recieving a key, hashing it, and having the database hash the hash
might actually work reasonably well. But not really.
By hashing it, you increase the number of members in the set of
keys that the database would consider "valid" (or that would be
such that would allow access) provided that the database hashes the hash.
Otherwise, you are back in the same f'mess. Which you pretty much are
anyway, as the "key" simply becomes the hash of the "real" "password" if
you bypass the frontend. A someone else mentioned, a shared secret setup
would go far to avoiding a problem like this. But, if you cannot trust
your connection for a shared secret setup, you have a bigger problem. ;-)

Have fun.

gh

>
> -Ron-