Community
Shared secret not working?
Links used in this discussion
A Nerd,
User (Posts: 2)
Sep 25, 2018 1:41:31 pm EDT
Support level: Free or trial
Viewer 6.8.0.1 (portable) on Win7 Pro 32 SP1
Host 6.8.0.1 on Win8.1 32 and also Win7 Home Premium 32 SP1
I use the online MSI configurator to create an install file. I choose to preconfig the host. I set a password and set shared secret and set for RUT to ask permission and auto-deny. I set it to email me with info.
I get the email, I add the connection using the code and connect to my host. I verify the shared secret on both the host and the viewer (for that particular connection properties). The viewer shared secret is blank/not configured, the host has the preconfigured shared secret. It appears that the shared secret is being ignored by the host (or I'm doing something wrong).
I've repeated this using the configurator to create an Agent file and to create a One-click file. I've changed the shared secret on the host with no apparent effects. I've rebooted the host multiple times.
This is a bit of a security concern for me as I believe the purpose of the shared secret is for the host to verify it is talking to the proper (and only the proper) viewer.
Guidance please...
Have a great day!
-Paul
Host 6.8.0.1 on Win8.1 32 and also Win7 Home Premium 32 SP1
I use the online MSI configurator to create an install file. I choose to preconfig the host. I set a password and set shared secret and set for RUT to ask permission and auto-deny. I set it to email me with info.
I get the email, I add the connection using the code and connect to my host. I verify the shared secret on both the host and the viewer (for that particular connection properties). The viewer shared secret is blank/not configured, the host has the preconfigured shared secret. It appears that the shared secret is being ignored by the host (or I'm doing something wrong).
I've repeated this using the configurator to create an Agent file and to create a One-click file. I've changed the shared secret on the host with no apparent effects. I've rebooted the host multiple times.
This is a bit of a security concern for me as I believe the purpose of the shared secret is for the host to verify it is talking to the proper (and only the proper) viewer.
Guidance please...
Have a great day!
-Paul
Conrad,
Support (Posts: 3049)
Sep 25, 2018 4:49:52 pm EDT
Hello Paul,
Thank you for your message.
This is the correct behavior. The purpose of shared secret is to provide the means to verify the identity of a remote Host, not to serve as another password or authentication factor. The program logic here is as follows: If there is a shared secret on the Viewer side (in connection properties) then the program performs the identity check. If it's empty , then the check isn't performed because the program assumes that admin doesn't want to perform identity check and it should let admin connect in.
That said in version 6.9 (as of Sep 25, 2018 in beta available for download) this system was totally replaced by a more modern certificate-based check. Now the process is automatic and doesn't require user intervention except only when there is certificate mismatch and the user is warned about it and asked for further actions. Here is a related documentation page for your reference.
By the way, in version 6.9 we also implemented two-factor authentication so if you want to add more security this is just what you need.
Hope that helps.
Thank you for your message.
This is the correct behavior. The purpose of shared secret is to provide the means to verify the identity of a remote Host, not to serve as another password or authentication factor. The program logic here is as follows: If there is a shared secret on the Viewer side (in connection properties) then the program performs the identity check. If it's empty , then the check isn't performed because the program assumes that admin doesn't want to perform identity check and it should let admin connect in.
That said in version 6.9 (as of Sep 25, 2018 in beta available for download) this system was totally replaced by a more modern certificate-based check. Now the process is automatic and doesn't require user intervention except only when there is certificate mismatch and the user is warned about it and asked for further actions. Here is a related documentation page for your reference.
By the way, in version 6.9 we also implemented two-factor authentication so if you want to add more security this is just what you need.
Hope that helps.
A Nerd,
User (Posts: 2)
Sep 25, 2018 6:06:17 pm EDT
Support level: Free or trial
Thank you Conrad for your characteristic rapid and comprehensive response!
I now see that MY logic does not match the program logic - I appreciate the explanation. Having said that, it seems rather backwards to me. I can think of all kinds of bad things happening if a rogue viewer (controller) connects to a given host, but I have a hard time picturing the same type of concern that I've connected to the wrong host.
I do understand that requiring the viewer to essentially be authenticated by the host would impact the convenience of firing up a viewer wherever the tech happened to be - but only such that the tech would need to enter the shared secret in the viewer as a default upon initial setup.
Perhaps I could add this 'shared secret VIEWER verification' option as a feature request. This way I could honestly tell clients/customers that no other RUT viewer can get to their computer. That their host would speak to ONLY MY viewer. The current implementation (and the certificate based scheme in the beta version) does not offer that assurance.
2FA brings it's own hassles into the picture and IMHO is not the great panacea that it's cracked up to be. It is, however a good OPTION to have.
Have a great day!
-Paul
I now see that MY logic does not match the program logic - I appreciate the explanation. Having said that, it seems rather backwards to me. I can think of all kinds of bad things happening if a rogue viewer (controller) connects to a given host, but I have a hard time picturing the same type of concern that I've connected to the wrong host.
I do understand that requiring the viewer to essentially be authenticated by the host would impact the convenience of firing up a viewer wherever the tech happened to be - but only such that the tech would need to enter the shared secret in the viewer as a default upon initial setup.
Perhaps I could add this 'shared secret VIEWER verification' option as a feature request. This way I could honestly tell clients/customers that no other RUT viewer can get to their computer. That their host would speak to ONLY MY viewer. The current implementation (and the certificate based scheme in the beta version) does not offer that assurance.
2FA brings it's own hassles into the picture and IMHO is not the great panacea that it's cracked up to be. It is, however a good OPTION to have.
Have a great day!
-Paul
Conrad,
Support (Posts: 3049)
Sep 26, 2018 5:00:32 am EDT
Hi Paul,
I see. And yet, the host identity mechanism as it can be seen in version 6.8 and earlier was to prevent just that - unauthorized replacement of the Host with a rogue/patched copy.Having said that, it seems rather backwards to me. I can think of all kinds of bad things happening if a rogue viewer (controller) connects to a given host, but I have a hard time picturing the same type of concern that I've connected to the wrong host.
The new PIN-code system in the beta 2 may fit for this purpose, although you must be using the self-hosted server in order for it to work. See more information in this blog post https://www.remoteutilities.com/about/blog/Remote_Utilities/6.9-beta-2/ . We will still note down your suggestion though.Perhaps I could add this 'shared secret VIEWER verification' option as a feature request. This way I could honestly tell clients/customers that no other RUT viewer can get to their computer. That their host would speak to ONLY MY viewer. The current implementation (and the certificate based scheme in the beta version) does not offer that assurance.
* Website time zone: America/New_York (UTC -5)