Paste Once and TeamViewer

Hello Daniel,

Thank you for reaching out to us regarding this,

I have a few questions which you can hopefully answer.

• Which version of RDM are you using?
• Which type of data source are you using?

The "Delays" is used to set a delay for how long we will allow the software, for example, to ask for the clipboard's content.

We also have the following knowledge base article regarding the Clipboard Diagnostic tool that I believe may be of interest:
https://docs.devolutions.net/kb/remote-desktop-manager/troubleshooting-articles/clipboard-diagnostic/

Let me know,

Best regards,

Hi Samuel!

I just updated from RDM 2023.1.25.0 to 2023.1.26.0 and it's the same behavior. We're using DVLS 2023.1.6.0 as the data source.

So after reading the article I understand there's no way to allow a process to read the clipboard without it being cleared, correct?

• When the access is allowed (default), the clipboard is cleared immediately
• If the process is in the Delay list, it will be cleared after the configured delay. That's meant to deal with apps that need to access the clipboard multiple times in order to paste.
• If the process is in the Disallowed list, it will not be able to access the clipboard and it will also not be cleared.

I think it would be useful to add more clearer wording to that dialog.
"Allowlisted" is wrong because it's not really a permanent list. It's just a log of which processes have been allowed.
"Add" could be changed to "Add to block list". Also an "Add to delay list" would be useful.

And again, I think a global delay would be useful, so you don't really have to configure any processes individually – even if it's block only. But I think an option to globally allow access to the clipboard for a specific delay would also be useful. That way any background processes can access the clipboard to sync or whatever, and only after all the automatic stuff happened, the clipboard will be cleared after a paste. It will allow to paste passwords on remote sessions like TeamViewer, or on the mobile phone. Right now I always have to use a text editor to paste and copy again, if I want to sync the clipboard somewhere.

I understand it is a security concern that passwords are synced to remote devices, but an option would be nice.

Let me know if I got anything wrong.

Another suggestion: Can you add an option to disable clipboard clearing in the Password Generator? Right now you can only set the number of times to paste, but not disable it. It happened at least once that someone* generated a password, pasted it twice (or more) to set it on an appliance, and then when they tried to paste it into the password manager to save it, it was already cleared. That's a fun way to lock yourself out of an account/appliance. To quote the LockPickingLawyer: "I now have a lock to which I don't know the combination"

Thanks!

By the way I found a little bug in DVLS Web: When you double click the version number at the bottom left it disappears :)


*) yes it was me

Daniel,

Thank you for the feedback we will take that into consideration.

First, with the situation you find yourself in with Team Viewer your only option is to go with Clipboard copy method set to Legacy mode. Long explanation below.

As for your questions:

When the access is allowed (default), the clipboard is cleared immediately

Correct, but only in Paste once (secure) mode

If the process is in the Delay list, it will be cleared after the configured delay. That's meant to deal with apps that need to access the clipboard multiple times in order to paste.

Correct, but only in Paste once (secure) mode

If the process is in the Disallowed list, it will not be able to access the clipboard and it will also not be cleared.

Correct, but only in Paste once (secure) mode

I think it would be useful to add more clearer wording to that dialog.
"Allowlisted" is wrong because it's not really a permanent list. It's just a log of which processes have been allowed.

Agreed, the Allowlisted header could become Processes Accessing Clipboard
and Blocklisted could be Processes Denied Clipboard (Blocklisted) or something along those lines.

"Add" could be changed to "Add to block list". Also an "Add to delay list" would be useful.

Agreed

And again, I think a global delay would be useful, so you don't really have to configure any processes individually – even if it's block only. But I think an option to globally allow access to the clipboard for a specific delay would also be useful. That way any background processes can access the clipboard to sync or whatever, and only after all the automatic stuff happened, the clipboard will be cleared after a paste. It will allow to paste passwords on remote sessions like TeamViewer, or on the mobile phone. Right now I always have to use a text editor to paste and copy again, if I want to sync the clipboard somewhere.

This is what Legacy mode does, it will clear the clipboard according to the "Clear clipboard delay".

Another suggestion: Can you add an option to disable clipboard clearing in the Password Generator? Right now you can only set the number of times to paste, but not disable it. It happened at least once that someone* generated a password, pasted it twice (or more) to set it on an appliance, and then when they tried to paste it into the password manager to save it, it was already cleared. That's a fun way to lock yourself out of an account/appliance. To quote the LockPickingLawyer: "I now have a lock to which I don't know the combination"

The copy to clipboard of the password generator will also follow the Clipboard copy method you've set. In the case of Legacy, it will be cleared after the delay, in the case of Paste once (secure), you can paste x times controlled by the Password Generator - Clear clipboard after setting.

Detailed explanation
Why Legacy mode?

Well, first we need to explain how the Windows clipboard works. The simple case is a process sends data (& format) to the clipboard and then a second process asks for the data (& format) for the paste. In the example of text, you send the data to the clipboard then all other processes can read the data and do whatever they want with it. This is like leaving a Post-it note with your password on your keyboard, you have no control who has access to the data. The only option is for the process to clear the clipboard after a given amount of time. In RDM we call this the Legacy mode.

Where things get tricky is with Past once (secure) mode. We use the clipboard mechanism of Delayed Rendering. For example, say you copy the entire content of a web page in a web browser, the copy action might look something like this: I'm ready to supply (Delayed Rendering) to any process data in any of the following formats [HTML, text, PDF] (Display Format). The idea here is to save on processing time, why would I generate the PDF format if you don't paste it. Once a process asks for a given format, the promising process is asked to supply the requested format of the data. Once it does, the data is now owned by the clipboard, think Legacy mode, we don't want to stay here long so we quickly replace the clipboard data with "" (empty string).

So how does RDM handle Disallowed or Delayed exceptions? Since we use delayed rendering, the control comes back to our process (RDM) when a paste request is done and we get to inspect the caller (1*) and then decide what action to take. In the case of disallowed we simply don't reply to the request and nothing happens, the call process can't get to the data. For delayed processes we will supply the data and delay the "clear" action for the given amount of time (ms).

So unless you put a 5-10000ms delay on TeamViewer the Paste once (secure) mode will never work for you. This is why I suggest you use the Legacy mode.

Crazy idea, thinking about it, we could possibly allow some processes, TeamViewer for example, to copy once. We would define a new Copy Once exception list. The logic flow would look something like this:

Before (I use TeamViewer here but this could work with any application):

• RDM copy username
• TeamViewer opens the clipboard via OpenClipboard and requests the clipboard value
• RDM supplies the value "username-01"
• TeamViewer gets the value
• RDM clears the clipboard

With the Copy Once exception list

• RDM copy username
• TeamViewer opens the clipboard via OpenClipboard and requests the clipboard value
• RDM supplies the value "username-01"
• TeamViewer gets the value
• RDM restarts the copy username (new delayed rendering)
• TeamViewer opens the clipboard via OpenClipboard and requests the clipboard value (again)
  • since TeamViewer is in the Copy Once List we would ignore the request
• Paste into NotePad would then work
• Paste within the TeamViewer application would also work since TeamViewer owns a copy of the clipboard from the first call
  • Paste as many times as you want in TeamViewer since RDM doesn't have any control over the clipboard within TeamViewer.

This might just be crazy enough that it could work. The only problem is documenting all of this, I know the existing KB is already lacking. The topic is somewhat complex to grasp and explain.

I hope this clarifies somewhat how things work in regards to RDM the clipboard and other applications. Believe it or not, there is even more involved here but I will leave that for another day/thread/post/topic/KB.

Best regards,

1* Some applications will always supply null when calling OpenClipboard, this limits what we can do.

P.S. I will let the DVLS team know about the double-click bug.

Hi Stéfane!

Thanks so much for the detailed explanation! It's exactly how I imagined it would work. But I also think the documentation and the GUI could be more clear about this. It is indeed quite complex for what it does.

The copy to clipboard of the password generator will also follow the Clipboard copy method you've set. In the case of Legacy, it will be cleared after the delay, in the case of Paste once (secure), you can paste x times controlled by the Password Generator - Clear clipboard after setting.

OK I see. It would be nice to be able to configure the Password Generator copy independently. When you generate a new password you often have to paste it a varying number of times, and it can be bad if the password gets cleared from the clipboard after you've set it but before it was saved. After it happened to me I try to remember to save the password before changing it. But for new users, if you're not used to the clipboard being cleared automatically it can happen. btw, please make Ctrl+C work in the Password Generator :)

Regarding the global delay:

This is what Legacy mode does, it will clear the clipboard according to the "Clear clipboard delay".

What I like to suggest is different: The global delay would *prevent* the clipboard from being cleared for a short time after copying. That way, background processes have time to (try) read the clipboard without it being cleared. Only after the delay has expired, when the user pastes manually, the clipboard is cleared. So it would still be a Paste Once scenario.

So the process would look like this:

• User copies password in RDM
• RDM starts the global delay timer (for example 100 ms)
• Background processes like TeamViewer and PhoneLink try to read the clipboard to sync it. Depending on settings and allow/blocklists, RDM allows or blocks access to those requests but does not clear the clipboard.
• The global delay timer expires
• The user pastes the password and RDM clears it immediately, or after a second configured delay, like it worked before.

I think the Delays and Disallowed lists could even be combined into a general "Rules" list, which is processed in sequence for each paste request. You set a filter and an action for each entry.

The filter would include

• Process name, command line (like before)
• time elapsed since copy (?)
• the copy source/type, e. g. username, saved password, newly generated password, OTP code ... (?)

The actions would include

• Allow access and keep clipboard
• Allow access and clear clipboard (after x ms)
• Block access to clipboard

There could be 3 different delay timers active in combination:

• One right after copying, to ignore any automatic requests from background processes (what I called global delay)
• One after a successful paste, so apps like Chrome can read the clipboard multiple times when pasting
• A longer delay that clears the clipboard after a timeout, so sensitive data doesn't stay in the clipboard forever. So basically Legacy mode and Paste Once mode can both be enabled/disabled independently.

The Status tab's "Blocklisted" and "Allowlisted" could be combined into a single log display, where each action (copied, access allowed, access blocked, clipboard cleared) is logged with timestamps.
Any "clear clipboard" action would actually just decrement the counter for "clear clipboard after x times" scenarios, or copy the next bit of information for scenarios like "copy username and password"

I really like the concept of the Paste Once mode, but the way it is implemented now is difficult to troubleshoot and configure. I hope my ideas are helpful!

Thanks again for the explanations!

Best regards,
Daniel

Hello Daniel,

I'm working in DVLS Web team and you wrote this in a previous comment :

By the way I found a little bug in DVLS Web: When you double click the version number at the bottom left it disappears :)

I just want to let you know that it is not really a bug, it is an hidden feature for us I would say. Our documentation team uses that to be able to make screenshots whithout version number in it. We have never thought that a user could find that. I hope you don't have any problem if we keep that behavior.

Best regards,

it is not really a bug, it is an hidden feature

That's funny! 😁 Thanks for letting me know.
I often double click text to select words (or triple click to select paragraphs).

Hi Daniel,

As for your suggestions, I will take all of it into consideration. Nothing is simple when it comes to the Windows Clipboard but I do like the ideas being thrown around here and I think I can even get it to work. I will add this to our hackathon list so that we can get a POC and see what can be achieved.

Unfortunately no ETA, I would love to be working on this today but I got other priorities.

Best regards,

Awesome, Thank you!

Hi! Reviving this thread for context...

How does "Paste once" work with the Windows clipboard history? Copied usernames and passwords don't seem to appear in the Clipboard history at all, but it also doesn't appear in the Clipboard Diagnostics window as Allowlisted or Blocklisted.

Regards,
Daniel

In RDM we flag the data as "sensitive" (via the flags, see example) to prevent the clipboard history window to pick it up and list it. Because they respect these flags the clipboard history never tries to access the clipboard for the value therefore there is nothing in Allowlsited or Blocklisted.

Note, not all third party clipboard history tools respect these defined types and will still put the values into the history.

Best regards,

Thank you! That's exactly what I suspected. Which API or library does RDM use for the clipboard functions? Might be interesting to play around with that myself.

PS: your "see example" link seems missing on the forum here, but in the notification email I got it's a lickable clink.

We call the Windows API directly

RegisterClipboardFormat
OpenClipboard
SetClipboardData
EmptyClipboard
CloseClipboard
GetOpenClipboardWindow
...

PS: your "see example" link seems missing on the forum here, but in the notification email I got it's a clickable clink.

Fixed, thanks

Best regards,

Here's another little nuance with Paste Once: I tried to copy a username and paste it to a browser inside an RDP session that is open in RDM, which didn't work.
I think the problem is, that the remote browser, like a locally running browser, tries to read the clipboard multiple times. But the process that reads the clipboard is RDM, so it doesn't get the needed delay applied.

After I added RemoteDesktopManager to the Delay list, it worked.

So, I still think a global delay for all processes would be a good option.

Thank you!

PS: Apparently PhoneExperienceHost (The Phone Link app) still syncs the clipboard to my smartphone, even with the "sensitive" flags set by RDM. Isn't that exactly what those flags are supposed to prevent? So this doesn't seem to work, and PhoneExperienceHost needs to be added to the Blocklist explicitly.

Here's another little nuance with Paste Once: I tried to copy a username and paste it to a browser inside an RDP session that is open in RDM, which didn't work.
I think the problem is, that the remote browser, like a locally running browser, tries to read the clipboard multiple times. But the process that reads the clipboard is RDM, so it doesn't get the needed delay applied.

After I added RemoteDesktopManager to the Delay list, it worked.

Correct, since the process is not on the local machine but rather being passed from the RDP client to the host we have no control over the paste action. Since our RDP is running embedded, the read request we receive from the OS identifies RDM as the clipboard requester. So at this point, your only option is to delay RDM as you did.

So, I still think a global delay for all processes would be a good option.

I like the idea, I will add this to my to-do list.

PS: Apparently PhoneExperienceHost (The Phone Link app) still syncs the clipboard to my smartphone, even with the "sensitive" flags set by RDM. Isn't that exactly what those flags are supposed to prevent? So this doesn't seem to work, and PhoneExperienceHost needs to be added to the Blocklist explicitly.

Correct, some/most of these clipboard sharing/backup type apps don't respect the "sensitive" flags this is precisely why we introduce the blocklist functionality. I will ask the documentation team to document PhoneExperienceHost (The Phone Link app) as being a potential problematic app.

Thank you!

Please consider my previous post here about the 3 different timers: https://forum.devolutions.net/topics/39461/paste-once-and-teamviewer#176237 (does that link work?)

Again, I really like the idea of Paste Once, but I think the way it's implemented could be much easier, without requiring manual exceptions for each process.

Regards,
Daniel

Hi! Sorry for using this old thread again, but I think it's still relevant :)

I noticed another little quirk:
When Paste Once is enabled, the "clear clipboard delay" option gets grayed out, but it's still active.
When you copy a password, the clear timer starts. Then, when you paste the password before the timer runs out, the clipboard gets cleared but the timer still continues.
Then when you copy something else in the clipboard (independently from RDM), the timer might delete your clipboard unexpectedly.

So I think when the clipboard gets cleared by Paste Once, it should also disable the timer.
And the "clear clipboard delay" option should not be grayed out when Paste Once is enabled, because it's still in effect.

Thanks!
Daniel

Hi Daniel,

I will investigate. As you pointed out, this is not the intended behavior, as they should be mutually exclusive.

Best regards,

Stéfane

So I had a quick look at the code.

When Paste Once is enabled, the "clear clipboard delay" option gets grayed out, but it's still active.

They grayed out might actually be the issue here. If you copy secure but never paste, you could want the clipboard to be cleared in say 10-30 seconds. So that makes sense. (see third point)

When you copy a password, the clear timer starts. Then, when you paste the password before the timer runs out, the clipboard gets cleared but the timer still continues.
Then when you copy something else in the clipboard (independently from RDM), the timer might delete your clipboard unexpectedly.

We should stop the clear timer once we paste, as we've already cleared the value so the clear timer is no longer needed. Make the "copy something else" work properly without being cleared.

So I think when the clipboard gets cleared by Paste Once, it should also disable the timer.
And the "clear clipboard delay" option should not be grayed out when Paste Once is enabled, because it's still in effect.

You are correct this is they way to do it. I didn't get this statement the other day when I read it. One step further if you copy secure, copy some random text, we should also disable the clear timer as we no longer control the contents of the clipboard.

Best regards,

Sounds good, Thanks!

There's still some other quirks and manual configuration for Paste Once to work properly. Maybe could you consider my suggestions above from 2 years ago? The global delays would remove the need to put individual processes into a allow/block list.

I agree, I would really love to rewrite the entire clipboard code. With all we've learnt over the years. We could auto-detect allow/block processes, while still allowing manual overrides.

How could we auto-detect? Using a honeypot, when we start a copy/paste action, any paste request within say 50ms of the copy action is most likely due to a process and not user interaction. I've yet to see a user click & paste within 50ms. Any process falling within the honeypot would get flagged automatically. In your case you would allow PhoneExperienceHost & TeamViewer to get the content but still allow you to paste.

Best regards,

Yes, or having the option to allow pasting without clearing the clipboard for 50ms, so copied passwords can be synced to remote sessions or to your phone etc. It's a security concern, but I would at least make it an option, because it is sometimes useful. Maybe add a quick toggle somewhere in the menu or status bar ("Allow automated access to clipboard: yes/no")

And the same goes for manual pasting, as some applications try to access the clipboard multiple times (hence the delay rules exists currently). After the 50ms initial delay, when the user pastes, there could be an additional 50ms delay where access to the clipboard is allowed multiple times, before it gets cleared.

Thanks for your consideration!
Daniel

Changes are done and will be available in the next beta release of 2025.1

Best regards,