yetangitu/OpenSTF
1
0
Fork 0
mirror of https://github.com/openstf/stf synced 2025-10-05 19:42:01 +02:00
Code Issues Releases Wiki Activity

Slightly improved VNC readme.

Browse source
This commit is contained in:
Simo Kinnunen 2015-10-13 03:24:17 +09:00
parent 5b5520b705
commit e68d8564f4
1 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

6
doc/VNC.doc
View file

@ -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.