On Sat, 5 Jun 2004, Quark AV - Hilton Travis wrote:
> > From: Manuel Kasper [mailto:mk at neon1 dot net] 
> > Sent: Saturday, 5 June 2004 05:12
> > On 04.06.2004 14:54 -0400, Jay Custin wrote:
> > 
> > > Just an idle question...
> > > 
> > > Is there a reason the PPPoE password is NOT encrypted on the webGUI 
> > > nor in the XML configuration file?  Just seems a bit odd.
> > 
> > MPD needs the password in plaintext form for CHAP 
> > authentication, and therefore we cannot one-way-encrypt it 
> > (unlike the system password).
> > We could encrypt it somehow, of course, but anybody with a 
> > passing understanding of PHP could just look at the m0n0wall 
> > source code and figure out how it's done. I abhor security by 
> > obscurity, so I'd rather have the password stored in 
> > plaintext in the config to make it clear that it's something 
> > worth protecting than giving the user a false impression of security.
> 
> If only there was a way in BSD (and Linux, for that matter) to have PPP
> passwords stored and processed after encryption...  It seems that the
> authors of the ppp apps don't agree.  Oh well, that's life.  :)

It's not the authors that disagree - it's the mathematics. :-)

There are basically three schemes for authentication of this type:

1) Cleartext passwords.  The client sends the password to the server,
which compares it.

2) Symmetric-key challenge/handshake.  The server makes up a random
number, encrypts it with the password, and sends the result to the client
to be decrypted and returned for comparison.  Or maybe it sends the
initial random number and decrypts the return.  Both variations are
equivalent.

3) Asymmetric challenge/handshake.  Instead of a single "shared secret",
the client and server possess matching halves of a keypair.  Procedurally
it's like #2, but the encrypt and decrypt use different (but
matched) keys.

For #1, password transmission is vulnerable to eavesdropping, although
that can be gotten around by using an encrypted channel.  Server-side
password security can be improved by storing a one-way hash of the
password instead of the password itself (in which case the server simply
hashes the client's password before comparing it.

Method #2 avoids the eavesdropping problem without "encryption", but
requires that the client and server share the *same* form of the
password.  A one-way hashed password doesn't cut it, because by definition
it wouldn't be possible to reconstruct the version that matches the
client's.  Hashing the password the same way on *both* ends simply makes
the hashed password the equivalent of the unhashed password, and doesn't
increase security at all (i.e., the attcker doesn't need to know the
"real" password, just its hash, which is exactly what the server stores).

Method #3 is best, since the server simply stores the public half of the
keypair.  Stealing it would not help another client access the server.
Unfortunately this approach isn't widely used, except by SSH.  For more
common things, it's either not in the standards, or too rarely implemented
to count on.  (Speaking of which, note that m0n0wall doesn't support RSA
authentication for IPsec).

Without #3, you have to choose between challenge/handshake and server-side
password hashing.  You can't have both.  You can of course use encrypted
plaintext passwords, to get both kinds of security, but PPP encryption
only encrypts data, not control information.


I don't entirely agree with the "security through obscurity" argument,
since there's a significant difference between trivially reading a
password from a config file and having to decrypt it with knowledge of
the code.

There are actually a few possibilities for protecting non-hashable
passwords in the config:

1) Encrypting with a user-defined passphrase.  This would make the config
file secure at the expense of requiring the user to enter the passphrase
on every boot.  This might be an acceptable tradeoff in some cases.  And
encrypting all relevant passwords with the same key means only one needs
to be entered to unlock them.

2) Encrypting with something unique to the box that's not "obviously"  
readable, e.g. something saved in BIOS flash or CMOS RAM.  The
availability of that is hardware-dependent.

3) Encrypting with a key stored separately on the "disk".  This doesn't
help security for someone attacking the box, but makes config file backups
on other platforms reasonably secure, which may be the most important
consideration in some cases.  Here, having *all* configuration info in a
single file is *not* what's wanted, for security reasons.  Naturally, the
user would need to rememember or securely back up the key separately, but
it would rarely need to change.

4) Encrypting with a fixed key.  This is essentially the "security through
obscurity" case, though I still contend it's an improvement with a
suitable disclaimer about its limitations.  It could actually just be #1
with a default passphrase, or perhaps even #3 with a default.

In all cases, I'd only encrypt the specific items that need it, so that
the worst that happens if the key is lost is that the user needs to
reconfigure the passwords.

> > Oh, and as for the reason why the webGUI input field is not 
> > defined as a password field: I wanted to minimize a possible 
> > cause of failure (mistyping the PPP password) without 
> > inconveniencing the user by making him/her enter it twice 
> > (some DSL providers like to assign excessively long 
> > passwords). It would protect against the "looking over your 
> > shoulder" kind of prying eyes, but I felt that the benefits 
> > outweigh that disadvantage.
> 
> If its in plaintext in the config, then plaintext in the WebGUI also makes
> sense.  If it is shown as "***" in the WebGUI, then this could give people
> the false sense of security that it is also encrypted in the config file -
> which it isn't and cannot be.  I'd rather have it in plain text - easier to
> confirm - as you suggested.

Though there's ample precedent for masking insecure passwords on-screen to
avoid the "shoulder surfer" problem.

At least it's not like the ATM that had both a physical keypad and a big,
readable-across-the-room touchscreen keypad, and "helpfully" blinked the
touchscreen buttons as the PIN was entered on the mechanical keypad. :-)

					Fred Wright