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?
-Ron-