Hello,
Thank you for your post.
I have some security related remarks/requests of which I am not really sure that they have been asked before (the forum doesn't have a search function).
You can search the forum using the search field on the blue bar above:
Blocking the connection is ok from a security point of view, but I would like to have a message saying something like: "Connection aborted, because host doesn't have the pre-shared secret"..
This is a good point. We'll add a message in one of the subsequent updates.
I wonder if it would be possible to have the RU Server (service) running under a restricted account instead of the System account.
I'm not sure this is possible but I will forward this question to our developers nonetheless.
As far as I can see now it is possible for unknown hosts to join my (public accessible) RU Server.
For now - yes, it is possible. But it cannot lead to any breach or security problems by definition. The Host can only grant access, it cannot "get access".
If you would work with pre-shared secrets for hosts and server, RU Server could block incoming connections that do not have the pre-shared secret.
This won't solve the problem. The problem of unwanted Hosts connecting to RU Server originates from the fact that an admin/tech shares their Host package - e.g. puts it on a website for everyone to download as part of a support service. Any settings that you put in the Host then will be cloned on whichever machine it is run.
Still, we'll give more thought to how we can ensure no unwanted Hosts can connect to the server. A unique PIN or (as you suggested) a shared secret can work but only in some cases. It's not a 100% solution, unfortunately.
If the host has a pre-shared configured and the viewer doesn't, the viewer still can access the host. While this might be useful in some cases, I would like to have the option in the host settings to deny the connection when a viewer doesn't have the pre-shared secret.
A shared secret is not a means or another tier of authorization. It is a means of confirming the
identity of the Host. That is, making sure that the Host wasn't replaced with another Host with the purpose of harvesting your password.
Therefore, if the corresponding connection in the Viewer doesn't have the shared secret field populated the program reasons that the user doesn't care about the identity of the Host and doesn't want to check it.
That said, in the upcoming version 6.9 we are adding 2-step verification (2FA) to the Host (uses Google Authenticator or similar app) . You'll be able to use that in order to strengthen your Host authorization.
Don't hesitate to ask me if you have other questions.