Question about security in Webconf


Hello @jofemodo

I’m Paulo and I am investigating the webconf auth for implements something similar in a project.

Point one

I observer that some methods have @tornado.web.authenticated, mostly get.
Why post methods haven’t? If it has a power for change the data, why it isn’t protected?

In other words, why do I need authentication to see current configuration, but I do not need to change settings in Zynthian?




Point two

Other point, I think that the cookie token need be random, not a deterministic and commited string

From tornado security docs

Tornado’s secure cookies guarantee integrity but not confidentiality. That is, the cookie cannot be modified but its contents can be seen by the user. The cookie_secret is a symmetric key and must be kept secret – anyone who obtains the value of this key could produce their own signed cookies.



@guysoft had commented that it would add a hotspot to the Zynthian image. Today, if the application is insecure, there are no problems, because it is necessary to access the network of the device to carry out some attack.

However, with the implementation of the hotspot, more chances of attack. Imagine someone ruining your performance live!

I thought about this problem previously and the solution I considered was to add a led to blink if the network is in use and a button to activate / deactivate the hotspot.



Hi @SrMouraSilva!

Thanks a lot for your analisys. You are completely right. Until now, security hasn’t been an issue because Zynthian boxes are not too exposed. But this is changing with the development of new features, so we should take care of it. We should improve the security in webconf, securing every API call and regenerating the cookie private key for authentication. Also, the system SSH keys should be regenerated too on the first boot. Finally, a button for regenerating all the keys will be added to the webconf, so already running zynthian boxes can be easily secured.

Kind Regards,


In ZynthianOS build the ssh keys are already generated at first boot :slight_smile:

I think all the LED and buttons described could be just added to the GUI.


Nice @guysoft !

I will add a little script for regenerating in current systems.
I’ve opened a issue in github.



Make sense. :grinning:

In my original problem, I don’t have a display and (yet) a security layer. So what I thought the easiest was this led strategy. :sweat_smile:


OK! Zynthian security is acceptable now:

  • All webconf API calls are now authenticated
  • webconf cookie secret is generated and stored in a config file. If the file is deleted, it will be regenerated on the next webconf start.
  • A button for regenerating keys has been added to the Security/Access tab. This action will regenerate the cookie secret and the system SSH keys.