question about network configuration in wpa_supplicant.conf

[Jouni Malinen]

On Mon, Jul 31, 2006 at 12:52:40PM -0400, Bryan Kadzban wrote:
> On Mon, Jul 31, 2006 at 06:41:05AM -0700, Osho GG wrote:
> > I know it would not be a good idea security wise to do so. However, I
> > am just trying to find some way to comply with the security guidelines
> > at where I am (one of the guideline is that no password should be
> > stored in plain text anywhere).
> 
> Yikes.
> 
> Well, as Jouni said, you could encrypt the password and then also
> provide a key.  If according to the guidelines a "key" is something
> different from a "password", then you could automatically connect.  But
> I would certainly treat them the same way, since with one you can find
> the other.

Well, I'm all for not storing keys or passwords in plaintext format on a
harddriver. However, that alone does not allow the desired "no
password/key to be entered for connection" feature.

> But otherwise, there's no way to do it that I can see, with or without
> changes to wpa_supplicant.  You can't store the MSCHAPv2 response,
> because it changes depending on what the challenge is.  You can't store
> a hash of the password, because that's completely equivalent to storing
> the password itself (someone could take the hash and use it to log on,
> just like they could do with the password).

Password hash could be stored for MSCHAPv2 and I think there is an open
case for adding this to wpa_supplicant (hostapd has support for it
already). This would make it unfeasible to figure out the original
password, but as you point out, it would not be any safer for MSCHAPv2
itself. The main difference here is that if someone were to use the same
password for both MSCHAPv2 and something else (which really should not
be done), only storing the hashed version of the password could prevent
the other use of the password being compromised.

> It looks like your requirements have a bug, in other words -- either
> "no password should be stored in plaintext anywhere" or "the connection
> needs to come up automatically" is impossible to satisfy.  It may be a
> small comfort to know that Windows breaks the rules too, though (by
> storing the MSCHAPv2-usable hash of a password in supposedly "protected"
> memory inside the LSA).

Well, automatic connection is not going to work, but there are ways for
making this more user friendly. Windows can use single sign-on for this
kind of authentication. Something similar could be implemented with PAM,
I would guess. I would not use the same password for loging and wireless
access, though. Instead, I would recommend storing the password in a
encrypted (e.g., with GnuPG) file and caching the key needed to decrypt
this password in memory for the session. This would be either directly
derived from the login password or asked separately and then cached in
some kind of agent (similar to ssh-agent).

If I remember correctly, there has been discussion on encrypted password
storage for NetworkManager. I don't know the details for this, so I
cannot estimate whether it would meet the requirements/desires discussed
in this thread.

Anyway, the current wpa_supplicant does not provide any internal
mechanism for this. However, password can be requested over the
ctrl_iface which would allow this kind of password daemon to be
implemented as an external program without requiring changes to
wpa_supplicant.

-- 
Jouni Malinen                                            PGP id EFC895FA