question about network configuration in wpa_supplicant.conf

[Osho GG]

On 7/31/06, Bryan Kadzban <bryan at kadzban.is-a-geek.net> 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

Thanks. I would give this a try. Do you know how the Network
configuration will look like in wpa_supplicant.conf for using such a
key?

> I would certainly treat them the same way, since with one you can find
> the other.
>
> 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).  This is even a problem on
> Windows machines, if the password is stored locally.  (Cached domain
> credentials seem to be a favorite target for anyone trying to steal a
> valid domain password.  And even the local hash of the password that the
> LSA stores, and uses when you lock and unlock your screen, is either
> exactly equivalent to the password, or unusable for MSCHAPv2, or both.)
>
> 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).
>

It is indeed a good comfort to have :). I would be happy with as
insecure system as Window (never thought I would say that about Linux
:) ).

> Unless someone has another idea...
>
>
>
>

Thanks for your help,
Osho