I love VNC. I've regularly used it for some time, and while I haven't needed it in the past couple months, it's a resource I would like to continue to use in the future.

However, with new reports about TeamViewer, it raises a question in my mind that I had somewhat stupidly decided was unimportant and ignored: how do I establish trust in the security of my connection?

I realize a significant part of that relies on trust in the (likely proprietary) software I am using to establish a VNC connection. However, were I using TeamViewer at that time (thankfully, I was not), none of the standard security checks would have been useful: I had 2FA, I had a unique password set on my account, and I'm not storing my passwords anywhere on my computer.

Is there a way to mitigate or minimize this security risk? How do I assess the threat to my security?

3 Answers 3


Is there a way to mitigate or minimize this security risk?


  1. Only use trusted remote-desktop software. Some operating systems come with a default one, though it may not always be the ideal piece of software. This software need not be proprietary, there are open-source options to choose fome.
  2. Use strong authentication, never short or simple passwords.
    1. For a super-secure setup, you can handle this be using a secured connection to the server, with something like an SSH tunnel. Using port-forwarding, the VNC server can be configured to only accept connections on the remote desktop ports from itself and not any external connections.
    2. If that's not an option, definitely use a strong random password and ensure that your communication to the server is encrypted. If you password is sent in plain-text, it can be intercepted. VNC itself it not necessarily encrypted.
    3. Additionally if possible, you can use a firewall to limit access to only the local network. Still use a password though, a compromised local device can still do damage you don't want to spread.

Since it depends on your situation (e.g. connecting from work to home or vice-verse, how much you can trust your IT team or people at home, your ISP, your operating system), I'll just give a list for the most paranoid setup:

  1. Use the most secure implementation you can - First, check the list here: https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software (look at the "Features" table where encryption is listed), reject the versions that don't have the features you need, and research the ones that look promising. (Don't trust descriptions though, since strong encryption may hide an insecure implementation). Encryption is just a "patch" to VNC's old RFB protocol, so be especially careful of projects where "compatibility" is highlighted.

  2. Isolate using Virtual machines - Run the server in a Virtual Machine, where you can limit the folders only to those you specify (shared folders) and so you can limit the ports as well. Install only the apps you must use remotely.

  3. Avoid relying on browser security - If the data you need to work with is very sensitive, make sure you have the most secure browsers possible on both ends. It's best not to use the browser for anything else other than VNC. (E.g. don't use PayPal from the same browser or user account running either the server or client).

  4. Long random passwords - Obviously use strong passwords - ideally from a password-protected password storage app (and not stored in the browser or elsewhere).

  5. Use unprivileged accounts - Make sure you're not running either end on admin accounts. Ideally create special, unprivileged user accounts for both the server and the viewer. If you're paranoid, run both server and client in dedicated virtual machines.

  6. Network/encryption - Set up a VPN between computers with good encryption. Or you may be able to rely on VNC's encryption alone (RealVNC?). It's up to you to decide whether you setup a secure network or use a secure protocol (VNC side). If you use both, that may hurt responsiveness. If you connect via hops (e.g. SSH tunnel), remember that you have to trust the server you're connecting through.

  7. VNC setup - Change the default ports and use a username and password with lots of weird/special characters to at least limit automated attacks. Disable VNC listener ports and any feature you don't need. Ideally you should be able to block the ports with a firewall when you don't need them.

  8. Keep malware detecting software running - That will at least limit other attack vectors which may use VNC for escalation. (Basically remote access to a computer with VNC gives an attacker more options, even if they didn't break in through VNC itself).

  9. Stay up to date & carefully pick what you install - Install only up-to-date, trusted and well-reviewed VNC clients, subscribe to any security notification sources and uninstall the client and server when not used. You may want to burn the installer onto a CD and install from there first - and then update before running.

  10. Prevent physical access to both machines - Use disk encryption on both machines, since physical access to either can allow access to the other.

  11. Mitigate against password interception techniques - It might be safer to avoid typing in the whole password for VNC at once (due to key loggers, etc.). You may want to cut-and-paste bits from a secure password store from multiple passwords to mitigate this.

Summary: the biggest threats related to VNC I believe are:

  1. Easy to guess/crack passwords that are reused for other services, stored in browsers on insecure not-updated operating systems.
  2. Having VNC and a browser you use (for work/home) on the same machine (virtual or real).
  3. Having your machines available to people you don't trust.
  4. Multiple apps installed (e.g. Skype, Internet Explorer, Outlook, etc.) along with VNC and/or using USB drives which can potentially have malware installed.
  5. Insecure publicly available network and encryption either too weak or turned off, insecure/outdated/buggy VNC implementation.
  6. Attack vectors for malware (operating system, browsers, usb drives, opened email attachments, instant messaging communicators, etc.) - combined with VNC, the damage can be enormous and swift.
  • 1
    "First, pick a version/implementation with the strongest encryption and features/requirements you can live with" That's not a silver bullet. A lot of software ticks the crypto buzzword checkboxes; nearly all of it still has catastrophic security bugs. Jun 3, 2016 at 4:45
  • Thanks @MattNordhoff, I thought it was self evident, but I'm glad you pointed it out. There are trade-offs between "picking something that looks ok quickly" vs "making sure the project is built around a solid security model, is actively maintained and regularly audited". Still, you're right: "AES-256" in a description means nothing and guarantees nothing. Jun 3, 2016 at 5:08
  • tiny nit: using ssh tunneling doesn't necessarily imply "hops" (that is, that content is in the clear on intermediate boxes.)
    – markhahn
    Aug 22, 2016 at 21:40

First of all, with VNC you have no security. While your password isn't directly transferred in plain text, it still uses a homebrew authentication protocol which DES-encrypts a challenge sent by the server using the password as a key. The password is limited to 8 characters.

Now, even if we ignore the password bit, the actual frames are transferred in the clear for anyone to see and eventually inject packets that will simulate keystrokes to potentially download malicious software to compromise your system and gain permanent access even if you kill your VNC server.

I would recommend either using a better protocol that has built-in encryption and key/certificate authentication or at the very least tunneling your VNC through a secure protocol such as SSH or IPSec.

You must log in to answer this question.