> On Apr 25, 2019, at 8:26 AM, K. Scott Helms <kscott.he...@gmail.com> wrote: > > People are missing the point here. This is _not_ a Comcast "issue" this same > data is available to every single cable operator in the US who deploys > bundled modem/router/APs that follow the CableLabs standard. They may or may > not expose the data to their end customers, but it's stored in their systems > and is often available to their support teams. > > http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt > <http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt> > > The same thing applies to most FTTH and xDSL deployments. They use TR-069 to > collect the data instead of SNMP but the object model is the same. The WiFi > MIB above is explicitly built to mimic TR-181 functionality. > > Scott Helms > > > > On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec <r...@gsp.org > <mailto:r...@gsp.org>> wrote: > On Wed, Apr 24, 2019 at 03:13:33PM +0000, Benjamin Sisco wrote: > > The bigger concern should be the cleartext portion of the subject. > > Yes, and the availability of all this to anyone who hacks Comcast > customer support. > > —rsk
I have yet to hear any discussion of the business value of access to WiFi network password, especially as compared to billing and identity data. Also, remote management of local networks by definition requires credentials stored off site from the customer. To the typical customer, loss of connectivity is much worse than a small chance of sharing the WiFi. Narrowing the discussion back to Comcast, credentials for “guest” WiFi seem to be more used than purloined SNMP MIB data.
