I'm deploying a web-based ERP system for a customer, such that both the server and the client machines will be inside the customer's intranet. I was advised in another question not to use TeamViewer to access the server, using more secure means instead, and so did I. But now I'm concerned about whether or not TeamViewer would be appropriate for the client machines, which are not "special" to this system in particular, but nonetheless I don't want to lower their current security, neither I want to compromise the computer on my end.

My question, then, is whether or not TeamViewer is "good enough" for simple remote desktop support, where it will be used simply to assist the users in the usage of the system, and whether or not I must take additional measures (like changing the default settings, changing the firewall, etc) to reach a satisfactory level or security.

Some details:

  1. I already read the company's security statement and in my non-expert opinion all's fine. However, this answer in that other question has put me in doubt. After some research, UPnP in particular does not worry me anymore, since the feature that uses it - DirectIn - is disabled by default. But I wonder if there are more things I should be aware of that's not covered in that document.

  2. The Wikipedia article about TeamViewer says the Linux port uses Wine. AFAIK that doesn't affect it's network security, is that correct?

  3. Ultimatly, the responsibility of securing my customers' networks is not mine, it's theirs. But I need to advise them about the possibilities of setting up this system, in particular because most of them are small-medium NGOs without any IT staff of their own. Often I won't be able to offer an "ideal" setup, but at least I wanna be able to give advice like: "if you're installing TeamViewer in this machine, you won't be able to do X, Y and Z in it, because I'll disable it"; or: "you can install TeamViewer in any regular machine you want, it's safe in its default configuration; only this one *points to server* is off-limits".

  4. My choice of TeamViewer was solely because it was straightforward to install in both Windows and Linux machines, and it just works (its cost is accessible too). But I'm open for other suggestions. I'm low both in budget and specialized staff, so I'm going for the simpler tools, but I wanna make a conscious decision whatever that is.

  • 1
    I prefer a self-destructing, on-demand solution like join.me.
    – Iszi
    Commented Feb 29, 2012 at 13:15
  • 3
    Join.me is a Logmein service that isn't exactly linux friendly. Something to keep in mind if you aren't in love with wine.
    – sup
    Commented Feb 27, 2013 at 22:51
  • 1
    @Joel I'm in love with wine, although I find mixing it with work makes me incredibly unproductive
    – deed02392
    Commented Aug 18, 2013 at 11:14
  • I would recommend deploying on premise RHUB remote support appliances. They work from behind your company’s firewall, hence are much secured as compared to hosted services.
    – user32972
    Commented Nov 8, 2013 at 9:50
  • UltraVNC offers a self-destructing client-initiated connection tool that's VNC compatible as well for remote-viewing Windows clients. Commented Dec 6, 2013 at 17:10

9 Answers 9


There's a couple of differences between using a 3rd party supplier (such as teamviewer) and a direct remote control solution (eg, VNC)

Team Viewer has advantages in that it doesn't require ports to be opened on the firewall for inbound connections, which removes a potential point of attack. For example if you have something like VNC listening (and it isn't possible to restrict source IP addresses for connections) then if there is a security vulnerability in VNC, or a weak password is used, then there is a risk that an attacker could use this mechanism to attack your customer.

However there is a trade-off for this, which is that you're providing a level of trust to the people who create and run the service (in this case teamviewer). If their product or servers are compromised, then it's possible that an attacker would be able to use that to attack anyone using the service. One thing to consider is that if you're a paying customer of the service, you may have some contractual come-back if they're hacked (although that's very likely to depend on the service in question and a whole load of other factors)

Like everything in security it's a trade-off. If you have a decently secure remote control product and manage and control it well then I'd be inclined to say that that's likely to be a more secure option than relying on a 3rd party of any kind.

That said if the claims on TeamViewers website are accurate it seems likely that they're paying a fair degree of attention to security, and also you could consider that if someone hacks TeamViewer (who have a pretty large number of customers) what's the chance that they'll attack you :)

  • Very insightful! Right now I'm inclined to trust TeamViewer, my own lack of expertise on this subject might make a custom solution more risky than a ready-made one, short term (as long as that solution is a good one, naturally). But I'll make sure to weight those arguments in my future strategy.
    – mgibsonbr
    Commented Feb 28, 2012 at 22:00
  • +1 for "everything in security is a trade-off". This is an answer to many questions
    – Shurmajee
    Commented Apr 4, 2013 at 4:42
  • I would not be so quick to discard the possibility of being a target just because, “what’s the chance” Commented Apr 7, 2018 at 8:11
  • @micsthepick There is a smiley. I think it was sarcasm, because obviously every teamviewer customer has a problem if the teamviewer service is compromised. Commented Sep 10, 2019 at 20:58

Take a look at this security analysis of TeamViewer. In short, it's definitely not secure on untrusted networks: https://www.optiv.com/blog/teamviewer-authentication-protocol-part-1-of-3


It is my recommendation that TeamViewer not be used on an untrusted network, or with the default password settings. TeamViewer does support increasing the password strength to a configurable length, and using alphanumeric passcodes, but it’s unlikely that casual users will have changed this setting.Keep in mind that there is a substantial attack surface in TeamViewer that needs more analysis such as the unauthenticated, plaintext communication between client to server (over 100 commands are supported and parsed on the client side), as well as many peer-to-peer commands, routed through the gateway server. Despite the danger to this much exposed attack surface, the risk is somewhat mitigated by an extensive use of std::string and std::vector instead of C-style strings and arrays.

  • 1
    That's pretty good info, I wish I could upvote you more than once! I'd just like to note that many of the dangers presented in the linked page can be mitigated by not leaving TeamViewer running unsupervised, instead only opening it when you need to, and closing it immediatly after use. That won't protect you against an eavesdropper, but if you can [as is in my case] you can also disable remote control, so an active attacker won't be able to do much damage.
    – mgibsonbr
    Commented Jun 1, 2013 at 9:47
  • 1
    @mgibsonbr: You can use the SE bounty mechanism to donate some of your rep to Bill for his answer. Commented Sep 25, 2013 at 15:38
  • 1
    @mgibsonbr, Bill, Please summarize the 3 pages and put up a summary on this answer.
    – Pacerier
    Commented Feb 16, 2015 at 11:13
  • The link above no longer works. Commented Feb 6, 2020 at 10:53

I just want to add an answer which I think hasn't been touched upon yet. When you connect via teamviewer to another computer, you share your clipboard with that computer (by default).

Therefore, everything you copy onto your clipboard is also copied onto the clipboard of the computer you are connected to. By installing a clipboard tracking application such as ClipDiary, on the host computer, you can keep a record of everything copied onto the clipboard by the person connecting to you.

Most of the answers here are focusing on the security of the computer being used as the host, but this is also a potential security issue for the computer connecting to the host, especially if you use a password management tool such as KeePass, as the host computer could potentially have a record of usernames and passwords (and potentially URL's if you also copy the URL from KeePass to your browser) on the clipboard history after your session is over.

  • 4
    Good point! It's very easy to forget this detail, and you never know what is in the clipboard at any moment, since it's invisible... so I'd rather play it safe and disable this option.
    – mgibsonbr
    Commented May 3, 2013 at 23:56
  • @JMK, Wow, isn't there a way to disable this automated clipboard behavior?
    – Pacerier
    Commented Feb 16, 2015 at 10:57
  • @Pacerier I think you can just uncheck Clipboard Synchronization under Advanced Options in Teamviewer's settings.
    – JMK
    Commented Feb 16, 2015 at 11:12
  • @JMK, It's odd that the other answers here are contradictory. Some says its secure while others say its not.
    – Pacerier
    Commented Feb 16, 2015 at 11:16
  • My experience with TeamViewer is that Clipboard Sync is turned OFF in the initial installation. You need to turn it on yourself, but after that point it stays on. And I'm not sure if the setting is per-connection. Commented May 27, 2015 at 6:03

I don't know enough about TeamViewer to give you an assessment of its risks or whether it is a good choice for your situation. But I'm going to re-iterate a comment from @Lie Ryan. If you deploy TeamViewer for this purpose, one potential way to reduce the risk of remote attacks is to set up a firewall (on both endpoints) which blocks all access to the TeamViewer ports except from authorized machines.

  • TeamViewer uses port 80 outgoing on both ends. I don't know if it uses end-to-end encryption or if the TeamViewer-company can see/modify the traffic on their relay servers. Commented Feb 26, 2012 at 17:28
  • 2
    The webpage claims that they use end-to-end encryption using public/private key cryptography, so that the routing servers cannot decrypt the traffic. But it does not go into details how the trust of the public key is managed. Commented Feb 26, 2012 at 17:32
  • @HendrikBrummermann "does not go into details how the trust of the public key is managed" - according to this answer, not very well...
    – mgibsonbr
    Commented Jun 1, 2013 at 9:53
  • @mgibsonbr, Which section exactly?
    – Pacerier
    Commented Feb 16, 2015 at 11:14
  • @Pacerier uh, it's been almost 3 years since I asked this question, but if I recall correctly it's this part at part 3: "Keep in mind that the initial RequestRoute2 response, containing the public key of the destination, is not authenticated in any way (...), so it can be trivially man-in- the-middled..." Also: "If peer-to-peer encryption negotiation fails for any reason, one of the clients (...) will send a CMD_RequestNoEncryption command, which will turn off all peer-to-peer encryption for the session. Turning off encryption is silent, with no user-noticeable effect."
    – mgibsonbr
    Commented Feb 16, 2015 at 15:17

About TeamViewer, there are a couple things that I think you should keep in mind:

  • You can't easily look at the source and verify its security, and it's a network-facing attack surface. That's not so nice – if you're able to make an OpenSSH server with password-based auth deactivated the internet-facing part instead, do that. (You might want to give the user a method to start/stop the server.) Through the OpenSSH tunnel, you could just use localhost-bound VNC to connect to the display. Of course, this method doesn't work so well if the PCs in question are behind a NAT/overzealous Firewall and you don't have a way to get behind that firewall. Ideas to get around it:
    • You could use a hack like http://samy.pl/pwnat/ to open them up to connections from the internet.
    • You could do the SSH tunnel in the reverse direction: When they want support, they start a script that makes an SSH tunnel to your support server and connects a TCP connection to the VNC server to the SSH connection. Your support server has the client's public key in its authorized_keys file with a forced command that connects the client to your reverse VNC client.
  • If you use it, make sure to never have a system running with that stupid 4-digit passcode system. Yes, they do have exponential lockout times, but first thing, you don't want support to be locked out that easily and second thing, well, what if someone just tries one random combination on 100000 PC running teamviewer? He'll get ~100 established connections without running into any lockout, I think – afaik, the lockout is completely client-side.

Teamviewer is not secure period. Think about it. Teamviewer can be configured to always use the same Partner ID and password. Similar code can be created and launched just by the user clicking on an email. Great tool? Absolutely..for guys like me who support a large bunch of remote users who can't tell a colon from a semi-colon. But secure? No way No how. Teamviewer allows remote access to a PC and can circumvent Cisco VPN or any other VPN security. This crap about the end user having to give out the partner ID and pass is just that...crap. This can be gotten around very easily. Don't get me wrong. I like Teamviewer. But don't kid yourself, it's not secure at all.

  • Do you mean not secure for the user or not secure for the server or both?
    – Pacerier
    Commented Feb 16, 2015 at 11:15

I would suggest a native solution such as VNC, enabling you to omit such workarounds as TeamViewer in WINE etc, as well as using the local operating systems package management utility to ensure that the solution stays up to date. For security, use an SSH tunnel. This ensures that all VNC communications are encrypted, including the initial VNC auth/password handshake. This is especially important as a lot of VNC implementations are rather insecure.

In addition as another respondant suggested, use IP filtering to ensure that only those at certain addresses are able to communicate with the VNC server.

  • If you this route you could also in theory extend the support to external clients through the use of a VPN. Much easier to block everyone except a list, then try to worry about everyone, and try to secure the network.
    – Ramhound
    Commented Mar 1, 2012 at 14:47

One way we handle it: if client requests TeamViewer availability, user starts TeamViewer on demand and admin kills it upon tasks completion. Another solution we once deployed in such a case, is that TeamViewer is started from an SSH session by the admin. Alternatively, you might look into "invite-me" desktop sharing tools. Or my favorite: mirroring the Xsession via SSH to your desktop.


Teamviewer gives the computer user the ability to give a remote session to is PC to anyone in the internet. So, the security of the network passes to the end-user! That's a no-go. I advise you to use VNC.

  • 1
    Some references, or more detail on the how might help the poster.
    – MCW
    Commented Oct 11, 2012 at 12:49
  • "the security of the network passes to the end-user" - I disagree. TeamViewer by itself does not perform any privilege escalation, so the remote operator can only do as much as the local user could do. There might be other reasons why another choice of tools might be better, but IMHO this is not one of them (the user either has or has not the authority to allow a remote operator, the specific tool being irrelevant).
    – mgibsonbr
    Commented Oct 29, 2012 at 20:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .