I loaded the script "http://find.zwave.me/zbw_new_user" a couple times. You will notice it generates a new private key each time. This is for the local service to connect to the z-wave server without password credentials.
This actually seems okay, the script should be loaded over https definitely but this ssh key part is really just giving a password to each device for connection.
> "using ssh as a transport mechanism for a web service is one of the worst practices you can use. SSL vulnerabilities are being spotted more frequently than ever now"
Just wanted to note that SSH doesn't really have anything to do with SSL (e.g., it doesn't operate over an SSL transport). Might just be a typo though. Still seems really sketchy that they're using a reverse bind to (presumably) punch through NAT rather than something sane like just using UPnP or simply requiring correct network configuration.
I see zero problem with using SSH, which happens to be a pretty secure protocol. In fact I would prefer it to HTTPS since it is not by default vulnerable to malicious CAs. Note for example that GitHub allows Git access over SSH.
When the author says that the system "exposes the private key", well, it's by design that the user can see it - since they need to use it to identify themselves to the SSH server. It's not much different from being assigned a password by the server. What could be improved is if it was transferred over HTTPS rather than HTTP, and of course also the install script.
(I only speak about the usage of SSH, it's possible that they still do something insecure..)
So the remote authentication bits are already out the window. It would be nicer if they included the host's public key in the installation package rather than eschewing it completely.
> These types of installers aren't inherently bad or evil, they just require a degree of trust between yourself and the source you are downloading from.
The Z-Wave protocol transmits keys in plaintext when setting up secure connections between devices on the mesh network. The rationale is that this should be a one-time event when installing the devices, while also requiring very close proximity to them. Most device don't even have the capability to run securely. It's typically only door and window locks.
Not any worse than installing an RPM/deb (which includes an embedded preinstall script) Or the normal "./configure / make / make install" pattern which gives a malicious distributor lots of boilerplate to hide in.
If anything it's probably safer since it's explicit and more likely to be audited.
One could argue that signed packages are still harder to check because publicly facing web servers are easier to hack, but you need to get the signature somewhere which is usually included in you distribution you downloaded through an insecure http or ftp connection.
That doesn't protect you from truncation attacks: almost no server out there sends a close_notify before closing the TLS connection, so few tools will throw an error when you receive an incomplete file.
It may be hard to exploit, but executing a script before you have completely downloaded it is simply a really bad idea.
This actually seems okay, the script should be loaded over https definitely but this ssh key part is really just giving a password to each device for connection.