question about network configuration in wpa_supplicant.conf

[Osho GG]

Thanks Bryan and Jouni for insightful comments

I think I will try to see if I can write some scripts that use GnuPG
and ssh-agent.

thanks,
Osho.

On 7/31/06, Jouni Malinen <jkmaline at cc.hut.fi> wrote:
> 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
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>