> Huh? The PAP protocol doesn't specify a thing about how the password
> is stored on the system. My pppd allows for encrypted passwords in the
> pap-secrets file, and for fallback to the system password database, but
> those are not part of PAP itself ( and I know of PPP implementations that
> don't allow them ).
No, but the *protocol* allows for encrypted (or preferably one-way-hashed)
passwords on the server. CHAP does not, because the passwords have already
been hashed, you need the plain text on the server to verify their
correctness, or the hash result would in effect become the password.
Quote:> Even when the PAP secrets are encrypted, if the authentication server is
> compromised the attacker has everything he needs. Remember that he doesn't
> need the cleartext of the secret to authenticate, only the encrypted form
> and a slightly-hacked pppd. That's a generic problem with shared-secret
You would need to hack the pppd on the server to overcome PAP using only
the hashed version of the password, because it uses the plaintext password,
to get past it from the client, you need the plaintext password.
For CHAP, because it is challenge-authenticate, you need to use the correct
salt, so grabbing the secrets exchanged on a particlar occasion does not
As for which is best, I think CHAP is a slightly superior protocol, since
it does not transmit in plaintext, but then the chances of a server
security breach are probably rather greater than those on a bugged serial
connections (which required either a telephone line bug, or a very serious
(ie physical or kernel level) breach of server security).