I have been reviewing some elements of security recently and observe there may be some vulnerabilities. I won’t discuss them here (yet) until I have validated them and hopefully have a resolution however… may I ask what purpose we are implementing security measures? The current constraints seems to be slightly contradictory. There have been messages about Zynthian only being a synthesizer and hence requiring little security and yet we impose limitations on users such as minimum password length. I think it would be beneficial to describe why we implement security and hence why we implement it in a particular way. We could waste lots of time implementing security measures that are not proportionate.
My thoughts:
Avoid inadvertent disruption or corruption, especially during performance
Someone connecting to the device may put extra load on it or they may change settings due to pure curiosity.
This may be avoided by simple password protection at the hotspot, webconf, console and ssh level.
Avoid intentional disruption or corruption
An adversarial actor may wish to interfere with the device. This may be malicious intent to spoil a performance or maybe just someone doing it to prove they can.
This kind of attack may require more robust protection such as cryptographic password protection of hotspot, webconf, console, ssh, etc.
Protect personal data
A user may include personal information within the data elements of Zynthian. They may use engine configuration for unexpected storage of data. They add extra applications or data storage for personal data storage.
This would generally be an intentional activity on the part of the Zynthian user who should consider the impact of such data being shared. This may be protected similar to the previous point.
Protect connected networks
Although Zynthian is a musical instrument it is also a computer with regular operating system. It provides tools for hackers to use as a staging point to access any connected networks which may include the Internet. I feel that Zynthian should have the same level of protection as any other computing device connected to the network. This may be greater or lesser depending on the network administrator’s policy. That may be home, school, venue, anywhere really.
Protect passwords
Protection of data in transit should be considered. If we decide we want to provide a high level of security then we should protect sniffing of data such as password. A recent change to password change routine has removed one such vulnerability. Basically, if we want it safe then make it safe!
Why is the password length constrained to minimum 6 characters? This feels like an arbitrary constraint that may have limited (if any) specific requirement. I would suggest it be up to the user (or local administrator) to define such constraints. If I want to have an empty password or a password that is 20 characters long with only unprintable content then that should be my choice. I will have made that choice with the benefit of a system that is intrinsically secure and so I decide how low I want to take the security.
Sorry for a rather long post on an old subject but I think it would be advantageous to agree why there is security so that we can agree what that security should look like. With it defined we can ensure that our design and testing implements it consistently.
.)
