On Wed, 2005-05-25 at 19:16 -0400, Bill Moss wrote: > A couple of points about decoding encrypted Cisco Group passwords (Secrets). > > 1. Anyone with an early version of the Cisco VPN client (4.0.3.B) can do > the conversion without using the web site. All the web site does is > automate the process. > > 2. Cisco has announced they will close the security hole but not when. > > 3. Other vpnc front ends like kvpnc have a similar import utility. > > 4. What liability is involved in exploiting this security hole? The web > site you reference has a note that the Secret should be obtained from > your network admin. Not all network admins may be happy about the decoding. > > 5. Whatever you do make sure the user is informed if the the import > utility fails to find the Secret for whatever reason. >
What concerns me is the fact that we store the "group password" on disk which means that if someone steals your hard drive they can use this exploit http://www.cisco.com/warp/public/707/cisco-sn-20040415-grppass.shtml to recover your personal password. Also note that if one is using vpnc with a config file /etc/vpnc.conf you're vulnerable to this attack. This is pretty bad. We simply cannot store the group password in plain text. It's not secure. So, I talked to Dan about this and what we came up with is that we shouldn't store the "group password" in gconf at all. What we will do (for vpnc) instead is simply prompt the user for two passwords when connecting - for convenience both of these can be stored in the keyring in an encrypted form. Which means that the user only needs to type in their keyring password for 2nd and subsequent connection attempts. Also note that if we need not rely on an external web-service to decode the "group password" in .PCF files which in my personal opinion is a grey legal area (this mail is legal advice though). However, workflow-wise the sysadmin will still need to distribute two passwords, not one, but such is life. So, Dan and I talked about implementing this in the following way: nm-applet will load the VPN-type dependent code that asks for authentication details. For vpnc we'll just ask for two passwords. This will fit nicely in with then plans about separating *all* the vpnc code (backend, ui widget for details and now authentication) from NetworkManager and placing it in a single tarball. Keep in mind that the grand plan here is to provide a stable ABI so any open source project (openvpn, openswan comes to mind) or VPN vendor can integrate with NetworkManager both backend- and frontend-wise. This specifically means that Cisco may implement their own code (that does something similar to vpnc), however we need to rethink the licenses of both nm-vpn-properties and, now, nm-applet to allow such integration (my idea is that we should dual-license these as GPLv2 and AFL2.0). We may only need this for nm-vpn-properties (of which I'm currently the sole copyright holder) but I'm not sure yet. I hope this clarifies. Cheers, David _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list