question about network configuration in wpa_supplicant.conf
Mon Jul 31 09:52:40 PDT 2006
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).
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
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).
Unless someone has another idea...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20060731/06d3b423/attachment.pgp
More information about the Hostap