From e68d8564f492b629ebb24f7a6bc9eddf8fb6e677 Mon Sep 17 00:00:00 2001 From: Simo Kinnunen Date: Tue, 13 Oct 2015 03:24:17 +0900 Subject: [PATCH] Slightly improved VNC readme. --- doc/VNC.doc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/VNC.doc b/doc/VNC.doc index 4c9ccc3a..40bcce1b 100644 --- a/doc/VNC.doc +++ b/doc/VNC.doc @@ -10,8 +10,8 @@ VNC authentication is very weak by default, and doesn't encrypt traffic in any w #### The way we do it -Since the authentication is very weak anyway, we might as well exploit it. The problem with the spec method is that since there's no username, it's difficult to know *who* wants to connect to a device. The only place for any kind of information is the password, but without knowing the password we can't decrypt the challenge response to see the contents. We could use a bruteforce method against our whole user database, of course, but that doesn't really scale. +Since the authentication is very weak anyway, we might as well exploit it. The problem with the spec method is that since there's no username, it's difficult to know *who* wants to connect to a device. The only place for any kind of information is the password, but without knowing the password we can't decrypt the challenge response to see the contents. While we could go through our whole user database encrypting the challenge with each user's password, that doesn't really scale in the long run, especially since we're interested in having per-device passwords as well (more on that later). -Instead, we send over a *static* challenge, e.g. 16 zeroes, every time. Then we simply identify the user by the returned challenge response itself, which will be unique for each password. This makes the authentication more susceptible to eavesdropping since responses from previous sessions could be reused, but given the already weak nature of the password this shouldn't be a massive downgrade, and we should be running inside an internal network anyway. For real security, all connections should be over a secure tunnel. +Instead, we send over a *static* challenge, e.g. 16 zeroes, every time. Then we simply identify the user by the returned challenge response itself, which is both unique and constant for each password. This makes the authentication more susceptible to eavesdropping since responses from previous sessions can be reused, but given the already weak nature of basic VNC authentication this shouldn't be a massive downgrade, and the app should be running inside an internal network anyway. For real security, all connections should be over a secure tunnel. -Furthermore, one password is only valid for a single device. This will enable interesting proxying and/or load balancing opportunities in the future as we should be able to expose every single device in the system via a single port, if desired. +Furthermore, each password is only valid for a single device. This will enable interesting proxying and/or load balancing opportunities in the future as we should be able to expose every single device in the system via a single port if desired.