"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> But it's not *really* secure. For one thing a bad guy could
> intercept the encrypted password and feed it to one of the
> password-guessing programs, like crack. It's not very robust to
> man-in-the-middle attacks, either. Do we know how predictable the
> salt-choosing algorithm is? What if a counterfeit server requested
> authentication with a carefully-chosen salt (like 0)?
I doubt the latter is a problem; AFAIK there are no weak salt values
in crypt() --- remember the salt is not a key.
However, the relatively small number of legal salt values (4096 IIRC)
is a weakness; an attacker who'd sniffed one encrypted password could
hope to get in by repeatedly connecting until he's challenged with
that same salt, and then he just gives the captured encrypted password.
If the salt-choosing code has any predictability then it might take
much less than ~4K tries, but that number is too small anyway.
I thought one of the major reasons for switching to a new protocol
is that we could include much wider random salt values in it, so
as to render that sort of attack impractical.
As for man-in-the-middle attacks, stealing passwords is the least
of our worries in that scenario --- the attacker could just wait
for login to complete and then insert his own queries into the
conversation. I think we have to rely on end-to-end encryption
like SSH or SSL to defend against that sort of thing.
> We are not in the business of creating security protocols. IMHO we
> should leave that to the people who are. If we want something better
> than the password scheme we have then we should adopt an existing
> standard.
Aw, that's no fun :-). But you're right, we should look to see if there
are existing standards that meet all the criteria we are looking for.
> Out of curiosity does SecurityFocus.com also criticise pppd for the
> same "problem"?
I checked and in fact there is nothing official about this "criticism";
it's just one message posted on a web bbs by someone with no obvious
credentials. Still, given the other headaches that reliance on crypt()
causes us, it seems to make sense to work on a replacement password
scheme that deals with more problems than just cleartext password
storage.
regards, tom lane
