nanog mailing list archives
Re: Comcast storing WiFi passwords in cleartext?
From: "K. Scott Helms" <kscott.helms () gmail com>
Date: Thu, 25 Apr 2019 13:53:05 -0400
Doug, I don't disagree, but things are pretty complicated, much more so than they might seem from the outside. First, if the configuration isn't stored there's literally no way to have a backup for most of the CPE vendors so there's definitely reason to have it duplicated in the service providers' systems. Very few allow for end users to download their router configuration via the admin page and I know of none that encrypt that configuration before it is delivered to the end user's computer. (It's also relevant that the usage for those vendors that do allow end users to backup the config is vanishingly low.) If we're looking at a TR-069 based system for managing the WiFi and router components it's not really feasible to do a real time grab of that data since that process can take up to ~5 minutes depending on your periodic inform settings in your ACS. That's because TR-069 is inherently a push technology (from the CPE to the ACS) rather than a pull like SNMP. The next piece is that a DOCSIS configuration file itself, which in some cases contains these parameters, is by the standard required to be delivered via insecure protocols, namely TFTP. Newer devices have options to allow for TLS secured HTTP, but that's very rare today in production provisioning systems, and in case the secured protocols are all still optional in the spec. In general the config file itself is stored in it's text format on the provisioning systems or if the file is dynamically generated the user specific parameters are held in a database with the general ones coming from a template for that class of service. Again, I'm not disagreeing with your premise but the service providers directly control a small piece of the overall process and we're still working with standards from earlier times. Most cable operators have gotten rid of their DOCSIS 2.0 (1.0 and 1.1 as well) but it's not uncommon to find a handful of users with (mostly customer owned) D2 devices that the provisioning and OSS systems still have to deal with. DOCSIS 3.0 devices are the majority and 3.1 devices are just now being rolled out in large numbers. In short, not everything is quickly retrievable, much of the configuration is in fact generated by the service provider and must be maintained because the modem needs to download its configuration every time it reboots, and the vendors and associations in the provisioning and OSS space have more input than the operators themselves. Scott Helms On Thu, Apr 25, 2019 at 1:16 PM Doug Barton <dougb () dougbarton us> wrote:
On 4/25/19 8:04 AM, K. Scott Helms wrote:Just so you know, if you have an embedded router from a service provider all of that data is _already_ being transmitted and has been for a long long time.Responding to a pseudo-random message ... If you are an average consumer and purchase a managed solution (in this case a WAP that comes as part of your package) I think it's perfectly reasonable for the vendor to manage it accordingly, even if said consumer doesn't fully understand the implications of that decision. In my mind, the problem here is not that the vendor has access to this data, it's that they are STORING it in the first place, and storing it in the clear to boot. In the hypothetical service call that we've speculated is the driver for this, the extra 15 or 20 seconds that it would take to pull the data via SNMP is in the noise. There are two mindsets that desperately need changing in the tech world: 1. Do not store data that you don't have a legitimate requirement to store 2. Do not store anything even remotely sensitive in the clear We live in a world of all breaches, all of the time. So we need to start thinking not in terms of just protecting said data from the outside, but rather in terms of limiting the attack surface to start with, and protecting the data at rest. So that WHEN there is a breach, whether from within or without, the damage will be minimal. As many have pointed out, this information is freely available via SNMP, so it's a classic example of something that didn't need to be stored in the first place. Doug
Current thread:
- Re: Comcast storing WiFi passwords in cleartext?, (continued)
- Re: Comcast storing WiFi passwords in cleartext? Sean Figgins (Apr 24)
- Re: Comcast storing WiFi passwords in cleartext? Yang Yu (Apr 23)
- Re: Comcast storing WiFi passwords in cleartext? Brandon Jackson via NANOG (Apr 24)
- Re: Comcast storing WiFi passwords in cleartext? Aaron C. de Bruyn via NANOG (Apr 24)
- Message not available
- Re: Comcast storing WiFi passwords in cleartext? Brandon Jackson via NANOG (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Benjamin Sisco (Apr 24)
- Re: Comcast storing WiFi passwords in cleartext? Seth Mattinen (Apr 24)
- RE: Comcast storing WiFi passwords in cleartext? Benjamin Sisco (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? K. Scott Helms (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Doug Barton (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? K. Scott Helms (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Tom Beecher (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? K. Scott Helms (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Saku Ytti (Apr 26)
- Re: Comcast storing WiFi passwords in cleartext? Seth Mattinen (Apr 24)
- Re: Comcast storing WiFi passwords in cleartext? K. Scott Helms (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? James R Cutler (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Mike Bolitho (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Töma Gavrichenkov (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Valdis Klētnieks (Apr 25)
- Re: Comcast storing WiFi passwords in cleartext? Töma Gavrichenkov (Apr 26)