Start a new topic

Security of Royal TS - Issues and Concerns - Hopes for the Future


I have some concerns about the security of Royal TS which I would like to share.

Royal TS is really unparalleled in flexibility, longevity, features and ease of use and we'd therefore like to deploy it in a sensitive / high-security environment on Privileged Access Workstations. So far, the CISO team won't let us because they deem the protections and security features of Royal TS insufficient.

I have collected some of the objections and issues that have been brought forward and I would like to detail them here (I hope this is the right place). I don't know if all of them are still valid in the current version or some features that mitigate this are already available, so I apologize in advance if some of the issues raised should be unjustified in some instances.

Security concerns that have been raised include:

1. The only protection Royal TS seems to offer is a simple password.

2. There are no multi-factor authentication options, even something simple like using an Authenticator app, or any biometric options such as a fingerprint scanner or smartcard reader. Windows does provide APIs for biometric devices and implementing TOTP that works with any Authenticator app should be very easy. Also, as far as I am aware, Royal Server already has some MFA options.

3. There is no option to use keyfiles (like e.g. in Veracrypt) as an additional authentication method (this is generally used to protect against hardware keyloggers as well). Again, this should not generally be very difficult to implement.

4. Royal TS does not optionally use the Windows Secure Desktop for the login form which means that any installed keylogger can easily snoop the master password. KeyPass and many other programs do support this, it has been requested before, and it should not be very difficult to implement.

5. There is no lock-out policy (i.e. quietly limit brute-force attempts by e.g. increasing wait time and always displaying a "wrong password" message after the 3rd or 5th try regardless of whether the correct password is entered).

6. There is no option to delete all credentials from a document after a number of failed login attempts (e.g. after the 10th attempt or so. This would also have to be done quietly.)

7. There is no reporting of failed login attempts (e.g. sending an email or logging this to the Windows log).

8. There seems to have been no security audit done on either Royal TS as a whole and/or the encryption part specifically.

9. It is unclear, what - if any - mechanisms are in place to protect an open Royal TS document from being exploited through any number of bugs through connections (such as malicious web pages, RDP, SSH or MITM attacks by a red team on the same network) which could then expose the complete Royal TS document with all credentials to the attacker.

10. There seems to be no option to have sensitive information copied to the clipboard automatically cleared after a given time of after it has been inserted once. Many password managers actually support this: They keep a username or password copied to the clipboard only there for 15 seconds or so until they overwrite it again. This could also be combined with Royal TS's function of "typing the clipboard" where the clipboard is cleared immediately after it has been typed out once (e.g. into an SSH session). This should of course be optional although I would reckon that most users do not need to paste a password multiple times in a row regularly and that this function is mostly used for single pastes only.

11. There is no built-in prevention that stops key sequences or pastes from going rogue and typing in the wrong window because of a focus error. It has probably happened to everyone who uses those features extensively that the focus is outside of Royal TS and an elaborate key sequence does all kinds of interesting things with the OS including typing cleartext passwords into any input field it can find. I realize that this might be difficult to prevent, although there could be options that say "Execute key sequence/paste clipboard only in the active Royal TS tab and stop immediately if there is no Royal TS tab in focus". Alternatively, you could mark key sequences as "sensitive" and select that they may only be written or typed into certain explicitly specified, selected and focussed tabs and connections (so that you cannot execute a sensitive key sequence by accident while having another tab focussed).

12. There is no information on memory protection by Royal TS, i.e. whether or not it uses e.g. CryptProtectMemory and CryptUnprotectMemory to protect passwords and connection strings, obfuscates or regularly overwrites memory to protect both credentials and its own security routines. I realize that this is not a trivial subject but there is lots of code, APIs and frameworks that can make such tasks easier. Also, Royal TS comes with licensing and activation features which customarily make heavy use of protection and obfuscation to frustrate cracking and reverse engineering so maybe some of the necessary routines for this are already implemented ;-)

13. There seems to be no option to automatically close or lock an open Royal TS document quickly with one click (Panic button) or after a given time with no user interaction has elapsed. Options that should be there, include lock document when workstation is locked (Win+L), the monitor goes dark or the screensaver comes on. Lock the document after the workstation has not been used (mouse/keyboard) for a given number of seconds/minutes. Lock the document after Royal TS has not been interacted with (e.g. running in background) for a given amount of time.


Given that Royal TS is routinely installed on admin workstations (also mobile devices) everywhere and not exactly a hobbyist's tool, it seems that much more investments should be poured into the security features and options to keep Royal TS as safe as possible. I have personally seen open Royal TS instances on-site with saved credentials to the server farms of multi-billion dollar conglomerates just sitting there... and even though I recognize that this is in large part the user's responsibility, developers must recognize that users/admins are extremely, extremely lazy and value convenience above anything else. In fact this is the very reason why they are using Royal TS in the first place! :-)

Therefore, Royal TS should make it as convenient and easy as possible to use any number of security features that don't require anything from the user (Windows Secure Desktop, Clipboard handling, internal isolation that prevent exposure of a whole document etc.) and combine them with options that make it even more secure for those who choose to go the extra mile (i.e. time-outs/auto-locking, multi-factor authentication, TOTP, keyfiles, logging, reporting etc.).

Side note:

I realize that security, as always, is a cost-center first and foremost and it can be difficult to argue why one should prioritze security features over other features that might at first glance be easier to sell. So security is always seen as a hedge at best, or a luxury. However, this can turn around quickly the very moment there is an actual attack or hacking attempt (examples are plentiful). I also believe that for Royal TS, exquisite and top-notch security features can and will open a whole new market and provide a unique value proposition for which users might well be willing to pay even extra, so if the developers need economic justification for adding a large number of extra security features, they might well consider offering an "enterprise feature license upgrade" that enables these (although it should not be outlandishly priced - like many other products in this space - as even small shops might benefit greatly from these features and might be willing to pay for them, as long as they are proportionate - the great thing with Royal TS has always been that procurement has been more or less a no-brainer, for large corporations as well as small shops, as the price point is very attractive across the board).

I would love to hear some feedback, especially by the developers and I am open to provide more details if I can on some of the points. If any of the issues raised are moot or have already been implemented, I apologize and would love to know so I can take note of this and share that information accordingly.

Thank you very much.
1 Comment

Hi Johnnie!

Thanks for your post. We welcome all the feedback. Let me go through each of your points:

1. - 3. That's correct. Since the .rtsz file is basically a simple XML file we can use password encryption to protect sensitive information, like passwords. Many users want to have the flexibility of XML to create their own files. So, adding additional security layers is quite difficult since all you need to do to circumvent it is to simply edit the XML. When you look at our lockdown feature, we actually encrypt the whole file to enable some of those additional security features. The main issue here is that users lose the flexibility of having a simple XML file. As you already mentioned, using the Royal Server product, we can do much more regarding security (like MFA). Also key file auth would be possible with Royal Server. For this I kindly ask you to put in a feature request in the Royal Server Ideas forum:

4. There's already a feature request for this:

8. and 9. We actually don't reinvent the wheel. We are using OS, framework and even 3rd party components. For example, XTS-AES encryption used in Royal TS is mainly done using a component from a 3rd party vendor There were situations in the past where users and security researchers reported issues and filed CVEs. So far we were able to mitigate/resolve all those issues in a timely fashion and have been transparent about this. Handling bugs or security related issues in the 3rd or even 1st party code (like OS or framework code) is much more difficult as we often don't know about it until MS (or the vendor) has fixed the issue and it's not really clear if our product(s) have been affected.

11. The key sequence task feature has been requested for a long time and we were hesitant to implement it at all. We know it can be dangerous, we know it can be fragile and unpredictable and we have declined that feature for a long time. A lot of users demanded it though and compared it to the functionality to AutoHotKey or similar products. In the end we decided to implement it because of the outcry in our community. I hate to do a gun comparison but it's quite simple: it's your foot! so be careful ;).

12. All passwords of your document (or any other "sensitive" data) which is encrypted on disk, is also encrypted in memory. If you do a memory dump, you will not be able to find your unencrypted passwords unless you created the dump in exactly the moment the password is being used for a connection where we need the unencrypted string, of course.

5. - 7., 10. and 13. Please enter a feature request individually for each feature. This way we can better track the requests and also see which one must be prioritized based on popularity. Some of the requested features may be trivial to implement but we do have quite a large backlog and are already working on V6 features.

I hope this answers most of your questions and I'm looking forward to see your feature requests.


1 person likes this
Login or Signup to post a comment