One time passwords

[Rafael Guimaraes]

Hi DRC,

I am using TurboVNC 2.2 for allowing remote execution of 3D applications (together with VirtualGL). My deployment includes a web portal that manages VNC sessions, controlling who has access to which session and other stuff. For this reason, I use the Java Viewer through javaws (I have both Windows and Linux clients). Since everything is controlled by the web portal, I am using one time passwords (generated by vncpassword command line). However, it seems to me that Xvnc stores just one OTP password at a time. Is this correct?

If I run vncpasswd twice, the first generated password no longer works. Is this behavior possible to configure? I have came across a situation where several users tried to open the same session almost at the same time and some of them were not able to open it (maybe because each of them generated a different otp and used them to access the session on a different order than the one that they were generated).

Any idea on how to overcome this?

Best regards,

Rafael

[DRC]

I'm BCCing a couple of people who developed the portal used by one of
the largest TurboVNC shops in the world (if not the largest.) My
understanding is that their portal only allows one user to "own" the
TurboVNC session. Other users must request to collaborate with the
owner, and when they make that request, the portal pops up a dialog in
the session that allows the owner to approve or deny the collaboration.
The collaborator is only allowed to connect (thus triggering the
generation of a new OTP) once the owner approves. I think this
effectively avoids the race condition you described, by basically
turning the session owner into a human mutex ("hutex"?)

Xvnc stores just one OTP at a time, and since the OTP is stored in an X
root window property (atom), this design represents a public interface.
Thus, it wouldn't be straightforward to change it. I would have to:

- Use a new X atom with a different name in order to support storing
multiple OTPs simultaneously.

- Validate the incoming VNC password against all stored OTPs, both in
the old atom and the new one.

- Extend vncpasswd so that it can modify both properties, to retain
backward-compatible behavior.

- Somehow limit the number of stored OTPs to a reasonable number, in
order to avoid a DoS-like attack.

The concept of an OTP is premised on it being a transient property of
the session. If multiple OTPs are stored, then there is nothing to
prevent a user from generating many different OTPs and never using them.
Thus, in order to store multiple OTPs, I'd also have to make sure that
they eventually expire. That starts to look like a very significant
undertaking, and before I would even consider it, we need to first
discuss why it is necessary and appropriate for multiple users to
connect simultaneously. As discussed above, generally TurboVNC sessions
are meant to be owned by a single user, with other users allowed in
temporarily for the purposes of collaboration. I understand that there
are potentially some limitations in the current OTP system, but I would
strongly prefer to work around those limitations rather than overhaul
the OTP system, if possible. Overhauling it would require funded
development-- unless there is a more straightforward way to work around
this that I haven't thought of yet.

DRC

[DRC]

From Santos Ltd:

"
Echoing DRC, a TurboVNC session is always owned by the user that started the initial Xvnc process, however there's nothing stopping us from allowing multiple different users to connect to that same TurboVNC session once it's running.

The confirmation dialog that we've implemented is launched by default to ensure that the owner of the session gets to decide whether they're happy to share their desktop. But, we have also implemented a "Pre-Authentication" facility that gives the session owner the ability to have "invited guests" connect to the session without the confirmation dialog being triggered.

In our implementation, when a user heads to the web portal and selects the session that they don't own, it will check whether that user is in the "invited guest" list and either trigger the confirmation dialog or let them straight through. The web portal code generates the OTP which is then inserted into a .vnc connection file (along with any other required connection parameters). The .vnc file is automatically downloaded from the web portal to the clients machine where it launches the vncviewer via file association. Once the vncviewer connection is made, the OTP becomes invalid and it's ready for the next user to do the same. The fact that it takes less than a second from the point that the web portal generates the OTP to the point where the vncviewer makes the connection, means that we don't see that race condition where a second OTP generation invalidates the first.
"

So it seems that their primary defense against the race condition is the design of their specific portal.  As I mentioned below, I'm open to the idea of allowing multiple simultaneous OTPs, but we first need to have a discussion regarding your workflow, so I can convince myself that such a solution is absolutely necessary.  Then I need to figure out whether there's any way to implement it without the solution getting too complex or disruptive, because if it gets too complex and disruptive, it falls out of the scope of a bug fix and becomes a new feature that I will have to get funding for, as well as put through a beta-test cycle.

DRC

-----Original Message-----
From: DRC [mailto:d...@virtualgl.org]
Sent: Friday, December 7, 2018 8:44 AM
To: turbovn...@googlegroups.com
Subject: Re: [TurboVNC-Devel] One time passwords

I'm BCCing a couple of people who developed the portal used by one of the largest TurboVNC shops in the world (if not the largest.)  My understanding is that their portal only allows one user to "own" the TurboVNC session.  Other users must request to collaborate with the owner, and when they make that request, the portal pops up a dialog in the session that allows the owner to approve or deny the collaboration.
The collaborator is only allowed to connect (thus triggering the generation of a new OTP) once the owner approves.  I think this effectively avoids the race condition you described, by basically turning the session owner into a human mutex ("hutex"?)

Xvnc stores just one OTP at a time, and since the OTP is stored in an X root window property (atom), this design represents a public interface.
Thus, it wouldn't be straightforward to change it.  I would have to:

- Use a new X atom with a different name in order to support storing multiple OTPs simultaneously.

- Validate the incoming VNC password against all stored OTPs, both in the old atom and the new one.

- Extend vncpasswd so that it can modify both properties, to retain backward-compatible behavior.

- Somehow limit the number of stored OTPs to a reasonable number, in order to avoid a DoS-like attack.

The concept of an OTP is premised on it being a transient property of the session.  If multiple OTPs are stored, then there is nothing to prevent a user from generating many different OTPs and never using them.
 Thus, in order to store multiple OTPs, I'd also have to make sure that they eventually expire.  That starts to look like a very significant undertaking, and before I would even consider it, we need to first discuss why it is necessary and appropriate for multiple users to connect simultaneously.  As discussed above, generally TurboVNC sessions are meant to be owned by a single user, with other users allowed in temporarily for the purposes of collaboration.  I understand that there are potentially some limitations in the current OTP system, but I would strongly prefer to work around those limitations rather than overhaul the OTP system, if possible.  Overhauling it would require funded
development-- unless there is a more straightforward way to work around this that I haven't thought of yet.

DRC

On 12/6/18 1:49 PM, Rafael Guimaraes wrote:

Disclaimer: The information contained in this email is intended only for the use of the person(s) to whom it is addressed and may be confidential or contain privileged information. 
If you are not the intended recipient you are hereby notified that any perusal, use, distribution, copying or disclosure is strictly prohibited. 
If you have received this email in error please immediately advise us by return email and delete the email without making a copy.
Please consider the environment before printing this email      

[Rafael Guimarães]

Thanks for the answer and sorry for the delay in replying you! Here I have developed a portal that works very similar to the way described by Santos Ltd. I don't have this confirmation dialog, just the pre-invited users (I control a list o full access guests and visualization guests). The workflow is pretty much the same.

I have been working like this for several years (since 2009, when there was no OTP) and this issue has arised just now. What happened was that our TurboVNC/VirtualGL portal was used for giving a course for around 15 people. They were all together in a lab. Then the instructor asked everybody to open a session that he has previously created and invited all 15 students. They all tried to open the session at almost the same time, that's why the race condition happened. Although the process between generating the OTP password and using it to open the session usually takes around 1 or 2 seconds, when 15 users tried to open the session "at same time", this 1 or 2 seconds were not good enough.

But I think that maybe this was a very particular case... Maybe I should just ask people to open sessions one by one or maybe I could try to rethink the portal workflow to implement some kind of workaround. I will think a little further about this issue! Thank you...

Best regards,

Rafael Guimarães

Em sexta-feira, 7 de dezembro de 2018 14:32:48 UTC-2, DRC escreveu:

From Santos Ltd:

"
Echoing DRC, a TurboVNC session is always owned by the user that started the initial Xvnc process, however there's nothing stopping us from allowing multiple different users to connect to that same TurboVNC session once it's running.

The confirmation dialog that we've implemented is launched by default to ensure that the owner of the session gets to decide whether they're happy to share their desktop. But, we have also implemented a "Pre-Authentication" facility that gives the session owner the ability to have "invited guests" connect to the session without the confirmation dialog being triggered.

In our implementation, when a user heads to the web portal and selects the session that they don't own, it will check whether that user is in the "invited guest" list and either trigger the confirmation dialog or let them straight through. The web portal code generates the OTP which is then inserted into a .vnc connection file (along with any other required connection parameters). The .vnc file is automatically downloaded from the web portal to the clients machine where it launches the vncviewer via file association. Once the vncviewer connection is made, the OTP becomes invalid and it's ready for the next user to do the same. The fact that it takes less than a second from the point that the web portal generates the OTP to the point where the vncviewer makes the connection, means that we don't see that race condition where a second OTP generation invalidates the first.
"

So it seems that their primary defense against the race condition is the design of their specific portal.  As I mentioned below, I'm open to the idea of allowing multiple simultaneous OTPs, but we first need to have a discussion regarding your workflow, so I can convince myself that such a solution is absolutely necessary.  Then I need to figure out whether there's any way to implement it without the solution getting too complex or disruptive, because if it gets too complex and disruptive, it falls out of the scope of a bug fix and becomes a new feature that I will have to get funding for, as well as put through a beta-test cycle.

DRC

-----Original Message-----
From: DRC [mailt...@virtualgl.org]
Sent: Friday, December 7, 2018 8:44 AM
To: turbovn...@googlegroups.com

[DRC]

OK, let me know. I would be open to implementing a server option (disabled by default) that would change the OTP behavior in a way that would make it work with your portal. Possibilities: (1) an option to allow a specified number of uses of the OTP before it expires, (2) an option to prevent the OTP from expiring prior to a specified timeout.

--
You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/2ec37d3c-cae2-43d0-a561-2e0717255f0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.