API security issue

Hello, comunitiy!

I am experimenting with Rhasspy and so far I do like the thing. But there is a huge security leak in the API at the moment. Let me explain you as it is step by step:

  1. I installed Rhasspy on my HA server under hassos as add on. O.k. how to pass commads? I was browsing the community and came accross mobile app, which is pretty nice, by the way thanks to that guy who developed it.
  2. I installed the Rhasspy mobile app and set it up - now I can pass commands to Rhasspy and train it - great!
  3. I studdy the thing for 3 days, some issues ofcaurse… Then I decided to open the ports on the rourter to pass commands to rhasspy from the internet - works, great! I can voicecommand from everywhere… But wait, what about the credentials? Where did I put a password or a token in the app? Nowhere! I start digging and understand that RHASSPY REQUIRES NO CREDENTIALS TO ACCESS IT"S SERVICES! So, anyone who knows the por tnumber may install the APP and send commands to my… Home Assisatant! What could be these, who knows… maybe you would want to give voice commands to your security system? Why not…

Work in progress:

But generally you shouldn’t directly forward ports on your router to internal services. A better solution would be a VPN. I can recommend WireGuard, which runs on many routers or even as a Home Assistant addon I think, and there are clients for virtually every operating system, including Android and iOS.


That’s why you must not open the ports. Rhasspy was designed to be offline, which in this case comes down to “disconnected from the internet”

If you really want it, use a vpn like koan mentioned. You can also install ZeroTier addon and app, that is software to securely creates a private network between all you devices.

You totally miss the concept of ‘designed to work offline’ - complitelly. Designed to ‘work offline’ means - not provide info to remote servers. Opening the port was done to access Rhasspy from my phone through the internet, while I am away, not for the Rhasspy to send something to another server for processing - I do not see how I brake the concep. By the way, using Google for STT or TTS does break the concept…

Rhasspy was newer designed to work ‘offline’ because IT IS A SERVER in your local network - there is no use of a server which is ‘offline’. And yes, you do communicate with Rhasspy VIA TCP/IP.

Why do you care about the open ports at all? It is like nobody can hack your WiFi? Or plug a wire into RJ45 and get an access to your network VIA DHCP, or setting the IP address manually? As soon as you are in the same network - anyone can access your HA though Rasspy security leak…

You misunderstood me, I am well aware of the concept. That is why I added “in this case”

My point was: there was no need for it to have a rugged security in place in the beginning. As koan stated, there are actions that might lead to these features in the future, but it was not designed with that concept at the start.

Sure somebody can hack your wifi and all that, but I think if that is the case you have bigger problems than this missing security feature.

The case at this point, in my opinion, is very simple:

  • yes, security can and probably must be improved
  • if you are concerned about it at this point, do not use it, add your own security layer or help the community be adding those features to Rhasspy :slight_smile:

Does anyone know exactly how Home Assistant handles its API tokens? Are they just JWT, or something custom?

For decent security, I think we’d need a session-based authentication mechanism for the web UI (probably using quart-auth). For API calls, a “Bearer: xxxx” style token in the headers should work. I just need to know a good library for that.

Security would be nice, but asking the app developer for an option to send the audio over mqtt could potentially be a very fast and secure fix for this.
It also has the benefit that you could use a “cloud broker” and let your local broker subscribe to it, that way people without public Ips could use it everywhere as well…