Speaker password feature needed ASAP!

With numerous Sonos Speakers, plus many more smart-bulbs, smart-plugs, wireless hubs, cameras, doorbells etc. I’d get to the stage that compulsory password authentication to use these things on a daily basis, would drive me nuts!.. It would just be far too inconvenient for any end user.

The device authentication on the LAN itself has to be sufficient for these type of things... if a hacker wants to play songs by 'Vera Lynne' and flash a few lights to let me know I left a network window open, then so be it. The focus should be on securing the LAN, not the individual devices.

In all seriousness, I do see LAN security as being very important and it has to come down to the owner/admistrator to be responsible for it. I personally don’t see it as a Sonos problem, or a Philips problem, or any other device manufacturer, who’s products are actually intended for use on 'secure' local networks.

The security for my network is, and always will be, down to me... I actually don’t want to shift that responsibility across to all my individual devices... in the same way that I don’t want to have locks on the internal doors in my home, that lead to the kitchen, or the bedroom etc.

Just one. Give me one. No dodging. No links. Give us details.

The last link I provided gives excellent examples. As a software developer I can conceive of others but I'm certainly not going to post them on the web.

You know your snipping does not preclude me actually quoting the original request?


Never said they did. However, if Sonos devices had the option for authentication this thread wouldn't exist.

Again with your nonsense. Sonos could 100% protect their API from both internal and external attacks and not come close to giving you what you wished for in your OP.

Sonos could 100% protect their API from both internal and external attacks and not come close to giving you what you wished for in your OP.

Now that is interesting. How do you propose they do that while allowing Airplay access without any authentication (which is what we have now)?

The device authentication on the LAN itself has to be sufficient for these type of things... if a hacker wants to play songs by 'Vera Lynne' and flash a few lights to let me know I left a network window open, then so be it. The focus should be on securing the LAN, not the individual devices.
First, the risk is far greater than playing a song or turning on a light. If you doubt it read this:

https://www.networkworld.com/article/3266375/internet-of-things/best-practices-for-iot-security.html

"Making matters worse is the fact that cybercriminals are incentivized to figure out new and more insidious ways to hack into even the most benign devices because they can provide a convenient gateway to more valuable systems. Your connected rice-cooker might not, at first-blush, appear to present much of a threat to the security of your home if it is compromised by an outside party. But if it can act as a gateway to more important devices on your network it might actually represent your most significant security vulnerability."

The fact is that some of the smartest guys in the industry disagree with you. Maybe you missed this last time so here it is again.

The INTERNET OF THINGS (IOT) SECURITY BEST PRACTICES paper might be educational for you and others that believe it is OK to have unsecured devices on your networks.

https://internetinitiative.ieee.org/images/files/resources/white_papers/internet_of_things_may_2017.pdf

"5. Use strong authentication

IoT devices should not use easy-to-guess username/password credentials,
such as admin/admin. Devices should not use default credentials that are
invariant across multiple devices and should not include back doors and
debug-mode settings (secret credentials established by the device's
programmer) because, once guessed, they can be used to hack many
devices.

Each device should have a unique default username/password, perhaps
printed on its casing, and preferably resettable by the user. Passwords
should be sophisticated enough to resist educated guessing and so-called
brute force methods.

Where possible we recommend two-factor authentication (2FA), which
requires a user to employ both a password and another authentication form
that does not rely on user knowledge, such as a random code generated via
SMS text messaging. For IoT applications, we especially encourage the use
of context-aware authentication (CAA), also known as adaptive
authentication, which use contextual information and machine-learning
algorithms to continuously evaluate risk of malice without bother to the user
by demanding authentication. If risk is high, then the subscriber (or hacker)
would be asked for a multi-factor token to continue having access."

Treeguy,

I guess I could go out into town and get run over by a bus whilst crossing the road, or even fall down a sinkhole, I’m just not as paranoid about these things or the raised internal network matters as you, or some others here, appear to be.

I do my very best to keep my network secure and even if the hacker gets in I doubt he, or she, would find anything that’s really worth stealing.. if they want to waste their time trying then good luck to them. I do use hardware firewall and software/encryption and keep things updated. I pay for my email to be scanned and filtered eexternally too, prior to receipt. I keep some data secure offsite and all my information and operating systems are incrementally backed up.

I just don’t want the huge inconvenience of now having to enter a password every time I do something in an environment that I consider to be secure already. I understand some folk are paranoid about their security, but I don’t want those things forced on me.

The house analogy and 'padlocks on internal doors' that I mentioned earlier is the same thing... I don’t want to lock/unlock a bedroom door each time I enter/exit the room, in my secure home... if my home is broken into, the thief still has to find and get access to the safe. I prefer to spend my money on the perimeter and the safe, so I then have the freedom to move around the rest of the place, unhindered.

I have read the documents you refer to and nothing in those have altered my position on this, not in the slightest.

Sonos could 100% protect their API from both internal and external attacks and not come close to giving you what you wished for in your OP.

Now that is interesting. How do you propose they do that while allowing Airplay access without any authentication (which is what we have now)?

Still ignoring my original request, I see.

Done with you.

Here is one example of the many exploits intruders use gain access to a network. If this researcher hadn't shared his results with Sonos our devices would still be vulnerable to this attack. This article is well worth the time to read:

https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325

"Like Google Home, Sonos WiFi speakers can also be controlled by a remote attacker (CVE-2018–11316). By following the wrong link you could find your pleasant evening jazz play list interrupted by content of a very different sort. That’s fun for simple pranks, but ultimately pretty harmless, right?

After a bit of digging I found a few other interesting links to be followed on the Sonos UPnP web server that might not be so innocent. It appears that several hidden web pages are accessible on the device for debugging purposes. http://192.168.1.76:1400/support/review serves an XML file that appears to contain the output of several Unix commands run on the Sonos device (which itself seems to run a distribution of Linux).

http://192.168.1.76:1400/tools provides a bare bones HTML form that lets you run a few of these Unix commands on the Sonos device yourself! The Sonos HTTP API allows a remote attacker to map internal and external networks using the traceroute command and probe hosts with ICMP requests with ping using simple POST requests. An attacker could use a Sonos device as a pivot point to gather useful network topology and connectivity information to be used in a follow up attack."

That last sentence is very important. By poking devices an attacker is learning what is on the net. The more information gained the greater the chances of finding a weakness that allows more access to the network. This type of attack is stopped in its tracks with authentication.

Once again, that was because some idiots opened up port 1400 for all the world to see. You would have to enter your router setup and free up that port for this to happen. Certainly one so consumed with security would never do something like that? Also, that type of attack has been plugged, with no need for a password on the app (not that a password on the app would do anything to intercept someone bringing up web pages on the Sonos UPnP web server).

Still waiting for one of the "many exploits" . . .

Once again, that was because some idiots opened up port 1400 for all the world to see. You would have to enter your router setup and free up that port for this to happen.

I disagree with your statement that this is about port 1400 being open on the router (it did not have anything to do with router/firewall settings, see this article https://en.wikipedia.org/wiki/DNS_rebinding). The issue is that Sonos assumes that the network will be secure and therefore they have not secured the Sonos API with authentication so the devices are vulnerable to this type of browser based attack). There is no such thing as a secure network if the network is connected to the internet or has wifi as part of the network architecture.

I agree with the sentiments expressed in the original post i.e. having some kind of control to restrict open access to the whole Sonos network when using AirPlay2. I have a separate post on related matter ; I have two apartments located one above the other, which both use the same router / wifi. Set up with separate Bridges hardwired to same router, and creating two Sonosnets, each unique to an apartment. Using Apps to control the speakers in this way maintains the integrity of the separate network, with no-one in one apartment being able to play music in the other. I'm considering making these separate homes "smart homes" for lighting etc using Alexa. Sonos One units would replace Play Ones. Using App controllers would be no different to existing set up. However, I think Airplay 2 functionality would make ALL speakers across BOTH homes be transparent as potential speakers, which could lead to annoying unwanted playback in the wrong apartment.
I have another home elsewhere which I've smartened with Echo Dots linked to Sonos. I think this gives me the choice of searching for Sonos products and then deselecting those not required. Using Echo Dots would I think achieve the "closed" Sonos environments required.
Some switch/ selector/ password to restrict open access to ALL sonos speakers would be greatly appreciated.
I can understand in the majority of cases, Airplay2 will fulfil most users' requirements. However, other like me and the premier poster require something a little bit more bespoke.