Re: A comment on NetworkManager

[Aaron Konstam <akonstam sbcglobal net>]

On Thu, 2006-05-11 at 12:25 -0400, Robert G. Brown wrote:
> On Thu, 11 May 2006, Aaron Konstam wrote:
> 
> > On Thu, 2006-05-11 at 09:51 -0400, Robert G. Brown wrote:
> >> On Thu, 11 May 2006, Russell Harrison wrote:
> >>
> >>> must remember to hit "reply to all"
> >>
> >> :-)
> >>
> >> While we're accreting wish lists, let me add mine:
> >>
> >>    1) NM should to be able to manage keys and protocols (including WPA
> >> and WPA-2, given that WEP is pretty much useless no matter how many bits
> >> it has:-) without having to unlock the keyring.  I know the
> >> key-unlocking problem will soon be solved "outside" of NM per se, but
> >> hey, the WEP key for myssid is preserved in e.g.
> >>
> >>   P key
> > .gconf/system/networking/wireless/networks/myssid
> >
> > This is  interesting, since the WEP key requested is for 13 characters
> > but the WEP key recoorded is only 10 characters. What is going on?
> >
> > However, my directories are 700 so only I can read it.
> 
> This is a (smart) user choice, of course, but many users or new account
> programs might create the tree 755 or whatever.  And besides, as long as
> it is stored even 700 in cleartext, using a "decryption" step via the
> keyring is just silly.  Either store it encrypted (only) or don't bother
> encrypting it.  I'm inclined toward having the choice -- a userspace 700
> DEFAULT security level on this part of the .gconf tree or at least all
> files containing keys OR not storing the keys there at all and using
> strict encryption.
> 
> This isn't an obvious choice to make -- most users would probably be
> just fine with the 700 option, especially for WEP keys. 64-bit WEP takes
> anywhere from five minutes to an hour of passive monitoring to break in
> the worst cases and WEP in general should never take anyone longer than
> ten to twenty hours to break, regardless of key length (the weakness is
> in the 24 bit initialization vector used in BOTH 64 and 128 bit WEP,
> transmitted in cleartext, which lets people statistically analyze
> traffic on easily discoverable broadcast SSID networks and deduce the
> static shared key).  Additional problems include its vulnerability to
> man-in-the-middle attacks because of its lack of host authentication,
> because most access points broadcast their ESSID, because tools like NM
> can reconnect your network without warning so that you "think" you're
> entering something into a secured encrypted channel not realizing that
> you've reconnected to a new WAP and the remote password you are typing
> is going out in cleartext (something that has happened to me already
> more than once, or would have if I didn't use additional layers e.g.
> ssh) and so on.
> 
Your post is extremely interesting but leaves me with a question and a
statement.
Question: I thought I was using 13 character WEP passwd but the file in
the .gconf records only a 10 character passwd. Why is this?

Now about locking. You choose a lock consistent with the security you
want to have. I am satisfied to have a lock and deadbolt on my house but
it is not completely secure. Someone would have to be crazy to spend 10
to 24 hours to crack mt WEP passwd. If I was a bank it would be
different. I am not  convinced yet that for the vast majority of users a
13 bit WEP passwd is not secure enough. I also agree removing the ESSID
makes it harder to figure out what access point you are connected to.
-- 
Aaron Konstam <akonstam sbcglobal net>