> The CHAP protocol's dependent on having a shared secret but it doesn't
> have to be a cleartext password....
The `shared secret' is effectly a cleartext password. Encrypting
a different string and giving both ends this encrypted version
doesn't change that.
Let's take our password to be P, and our encrypted password (via
a one-way hash or something similar) to be E(P).
Now, with PAP authentication, we recieve Q from the remote host,
apply E() to it, and compare E(Q) to E(P). If they're the same, we
authenticate the user. Note that P is never present on the
authenticating system, just E(P). If someone should get ahold of
the user authentication information, he has only E(P), which is
not enough information to be able to log into the account.
With CHAP, however, it doesn't matter whether the shared secret is
`encrypted' or not, it's still the same on both ends. The authenticator
generates a random number, R, and sends it to the remote host. It
then applies a one-way hash function F() to it, getting F(P,R) or
F(E(P),R) or whatever you like. The remote system does the same,
and the authenticator compares the value it gets back; if it matches,
it authenticates the remote host. That means that, whether you use
P or E(P) or whatever, the authenticator has the information
necessary for the remote host to log in, and if that information
is compromised, you can log into the system. There's no way around
this, as there is with PPP. What the authenticator holds is, for
the purposes of authentication, plaintext.
This is why the CHAP RFC itself says
CHAP requires that the secret be available in plaintext form.
Irreversably encrypted password databases commonly available
cannot be used.
> M*crosoft created another, non-standard, algorithm that uses an
> encrypted password as the shared secret. The only advantage is that
> the original password can't be recovered (and used elsewhere) if one
> end is compromised, there is no other increase in security.
That's not even an advantage; you're just using a different password
with this scheme. If anything, this is worse, because you're in
some way relating an exposed password to other passwords of yours
presumably in use elsewhere.
cjs
Curt Sampson cjs@portal.ca Info at http://www.portal.ca/
Internet Portal Services, Inc. Through infinite mist, software reverberates
Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.