JVNC Security Guide

This guide explains what each security option does, what it protects against, what it does not protect against, and the recommended configurations. Read §1 before exposing JVNC to the internet.

1. The honest summary

Best: put both machines on a VPN (Tailscale, WireGuard) and never open a router port. JVNC is then unreachable from the internet regardless of its own settings. Use JVNC's layers on top as defense in depth.
If you must port-forward: enable TLS + approved client certificate + one-time code. The client certificate is the load-bearing layer — without it, an internet-exposed port is protected only by a 6-digit code and rate limiting.
Nothing is bullet-proof. JVNC's protocol code is small and tested but not independently audited; a compromised client device (stolen certificate + secret) has full access; and whoever gets through the handshake controls the PC as your Windows user.

1b. The classic VNC dangers, and how JVNC answers them

Everything you've read about VNC being unsafe is about stock VNC. Here is each classic warning and what JVNC does about it:

The classic danger	How JVNC answers it
Bots scan port 5900 and brute-force the password.	Per-address lockout (5 failed handshakes → 15-minute ban, plus a 1-second delay on every try), so brute force dies. And the public-address rule (default on) refuses any internet-address connection unless it presents an approved client certificate — a random bot is dropped before it can try a single password.
The password can be captured in transit.	The password never crosses the wire: JVNC uses a PBKDF2 challenge/response, so there is nothing to sniff or replay.
VNC is unencrypted — coffee-shop Wi-Fi can read your screen and keystrokes.	Built-in TLS 1.2/1.3 encrypts everything (screen, keystrokes, files, codes), and the client pins the server certificate so nobody can sit in the middle.
An exposed port is inherently unsafe.	Approved client certificates (mutual TLS): without the private key from one of your enrolled devices, the handshake cannot complete at all — so even an open port only answers your own machines. Add TOTP for a second factor.
You must open port 5900 and juggle modem + router + firewall rules + a changing home IP.	You don't have to open anything. Reverse connection has the PC dial out to your waiting viewer (routers allow outbound by default — zero inbound rules), and a VPN (Tailscale/WireGuard) puts both machines on a private network so nothing faces the internet. Either way there is no port to forward and no dynamic-IP allow-list to maintain.

Bottom line: the scary articles describe the old way. Put the server behind a VPN (or use reverse connection), turn on password + TLS + client certificate, and you have none of those exposures.

2. The layers (Server → Security…)

All layers are independent and can be combined. With every layer off, the server speaks plain, unencrypted VNC and any VNC viewer can connect (suitable only on a trusted LAN/VPN). With any layer on, only the JVNC Client can connect.

2.0 Require a connection password (default on)

On first start the server asks you to set a password (8+ characters). It is stored only as a salted PBKDF2-SHA256 hash (100 000 iterations). On connect the server sends the salt and a random nonce; the client derives the same hash from the typed password and answers with an HMAC of the nonce — the password itself never crosses the network and a captured exchange cannot be replayed.
The client can remember the password per server, encrypted with DPAPI for that Windows account.
Turning it off shows a warning every time, and the server logs a warning at start whenever no password, one-time code or client certificate is required. Turn on TLS as well whenever the port is reachable from untrusted networks, so the whole exchange is encrypted end to end.

2.0b Standard VNC viewers (phones, TightVNC, TigerVNC, bVNC…)

Allow standard VNC viewers (default on) offers the classic RFB security types alongside JVNC's own: VNC Authentication (16-byte DES challenge) when encryption is off, or VeNCrypt X509Vnc (TLS 1.2/1.3 with the server certificate, then VNC authentication) when encryption is on. Viewers that support VeNCrypt — bVNC and AVNC on Android, TigerVNC on desktop — therefore get an encrypted, password-protected session without any JVNC software.
The viewer password is a separate credential: classic VNC authentication is limited to 8 characters and DES, so JVNC does not reuse your strong connection password for it. Set it under Set viewer password…. If no viewer password is set, stock viewers can connect only when no password is required at all.
Stock viewers are never offered while a client certificate or one-time code is required (they cannot provide either), and the lockout, allow list and public-address rule apply to them like anyone else.
The JVNC client always chooses the JVNC security type (250), so JVNC-to-JVNC connections keep every layer regardless of this setting.

2.1 Encrypt connections (TLS)

The server creates a self-signed certificate on first use (%APPDATA%\JVNC\server.pfx, RSA-2048, 10 years). TLS 1.2/1.3 encrypts everything: screen, keystrokes, files, codes.
The client pins the server's fingerprint on first connection ("trust on first use"). The dialog shows the fingerprint — compare it with the one in the server's Security dialog before accepting. If the fingerprint ever changes, the client shows a prominent warning: either the server regenerated its certificate, or someone is intercepting the connection.
Protects against: eavesdropping, tampering, and (after pinning) impersonation of the server.

2.2 Require an approved client certificate (mutual TLS)

Every JVNC Client generates its own certificate (client.pfx). The server accepts only fingerprints in its Approved client fingerprints list.
Enrolling a device: open the client's Security… dialog, copy This client's certificate fingerprint, paste it into the server's list. Or connect once — the server logs the fingerprint and the Security dialog offers Approve last rejected client. Do this while you can verify the device (e.g. physically present or over another trusted channel).
Protects against: anyone without one of your devices' private keys. This is the strongest layer and the one that makes internet exposure reasonable.
Implies TLS.

2.3 Require a one-time code (TOTP)

Standard RFC 6238 TOTP: 6 digits, 30-second window, SHA-1 — compatible with Google Authenticator, Microsoft Authenticator, Authy, 1Password, etc. Enter the secret manually or paste the otpauth:// URI into any QR-code generator and scan it.
The client either asks for the code on each connection, or stores the secret (Client → Security…) and fills it in automatically. Storing the secret turns the code into "something the device has" — still useful (prevents replay, adds a secret to plain connections) but no longer a second factor for that device.
The code is never sent as-is: the client sends HMAC-SHA256(code, server nonce), so a captured exchange cannot be replayed. The server accepts the current window ±1 (clock drift up to 30 s).
New secret invalidates all authenticators and stored secrets.
Protects against: password-less connection by someone who obtained a device's certificate but not its authenticator; brute force is limited by the lockout (§2.6).

2.4 IP allow list

Comma-separated IPs or CIDR networks, e.g. 192.168.0.0/24, 100.64.0.0/10. Empty means anyone.
Checked before anything else; rejected addresses are logged and get no response.
Useful as a filter, weak alone: source addresses can be spoofed in theory, and mobile devices' addresses change constantly. 100.64.0.0/10 covers all Tailscale devices.

2.5 Listen on (bind address)

Restrict the server to one network interface, e.g. your VPN address, so it is never reachable via the internet-facing interface at all. Takes effect after Stop → Start.

2.6 Automatic protections (always on)

Lockout: an address that fails the handshake 5 times is banned for 15 minutes; every failed attempt is delayed 1 second.
Public-address rule (default on, can be disabled): connections from non-private source addresses are refused unless Require client certificate is enabled. Private = LAN ranges (10/8, 172.16/12, 192.168/16), VPN/CGNAT (100.64/10), link-local, loopback. This stops an accidental "plain VNC on the internet" configuration.
Approve each connection (optional): the person at the PC gets an Allow/Deny prompt for every authenticated connection before it proceeds; denials are logged.
Idle timeout / max session (optional): a session with no input for N minutes, or older than N minutes, is disconnected automatically.
Stuck-input release: when a client disconnects, all held keys and mouse buttons are released.
Secrets at rest: the TOTP secret is encrypted with Windows DPAPI for the current user; the settings file is useless on another account or machine. Certificates (PFX) are protected by NTFS permissions of your profile — treat %APPDATA%\JVNC as sensitive.

2.7 The mechanisms, precisely

Layer	Mechanism
Password at rest	PBKDF2-HMAC-SHA256, 100 000 iterations, 16-byte random salt, 32-byte verifier. Only the verifier is stored; the password is not recoverable from it.
Password on the wire	Server → 16-byte salt + 16-byte random nonce. Client → `HMAC-SHA256(key = PBKDF2(password, salt), msg = nonce)` (32 bytes). Constant-time comparison. The password never leaves the client; a captured proof is useless for any other connection.
Encryption	TLS 1.2 / 1.3 via Windows SChannel (`SslStream`); RSA-2048 self-signed X.509 certificate, SHA-256, 10-year validity, created on first use and kept in `%APPDATA%\JVNC\server.pfx`.
Server identity	Trust-on-first-use pinning of the SHA-1 certificate thumbprint per host on the client; any change requires explicit re-acceptance after a warning.
Client identity	Mutual TLS: the client presents its own RSA-2048 certificate; the server accepts only thumbprints in its approved list (checked in the TLS validation callback, so unapproved clients never reach the protocol).
One-time code	RFC 6238 TOTP (HMAC-SHA1, 6 digits, 30-second step, 160-bit base32 secret), accepted for the current step ±1. Sent as `HMAC-SHA256(key = code, msg = 16-byte server nonce)`, never as the bare code.
Secrets at rest	Windows DPAPI (`CryptProtectData`, current-user scope, application entropy) for the TOTP secret and any remembered client passwords.
Network filtering	IP/CIDR allow list evaluated before any bytes are exchanged; optional bind to a single interface; non-private source addresses (anything outside RFC 1918, 100.64/10, link-local, loopback, IPv6 ULA) refused unless mutual TLS is on.
Brute-force control	Per-address counter: 5 failed handshakes → 15-minute ban; 1-second delay on every failure; success resets the counter.
Protocol	When any layer is on, the server greets with `JVNC-000.01` + a flags byte instead of the RFB version, performs the layers in order (TLS → password → TOTP), then runs standard RFB 3.8 inside the encrypted stream. With every layer off it is byte-for-byte standard RFB.
Failure hygiene	Any handshake failure closes the socket, counts toward lockout and is logged with the reason; all held keys and mouse buttons are released when a client disconnects.

3. Recommended configurations

Scenario	Settings
Same LAN, trusted household/office	Password (default) is enough; TLS recommended.
Over a VPN (Tailscale/WireGuard)	Password + TLS (+ TOTP); allow list `100.64.0.0/10` (Tailscale) or your VPN subnet; bind to the VPN address.
Router port forward (internet)	Password + TLS + client certificate + TOTP; public-address rule on; allow list if your remote locations have fixed addresses; non-default port.
Public exposure without a client certificate	Not recommended. If unavoidable: TLS + TOTP + allow list + non-default port, and understand the residual risk (6-digit code + rate limit).

4. Operational advice

Run JVNC Server as a normal user unless you need to control elevated programs (then run it as administrator — this also lets a remote user control elevated programs).
Keep the Windows Firewall rule limited to the profile you need (Private/Domain rather than Public) when using a VPN.
Review %APPDATA%\JVNC\server.log periodically: rejected addresses, bans, unapproved certificate attempts and successful handshakes are all recorded with timestamps.
Revoking a device: remove its fingerprint from the approved list (and generate a new TOTP secret if the device also had the secret).
Back up %APPDATA%\JVNC\server.pfx if you want clients' pins to survive a reinstall; otherwise clients will see a "certificate changed" warning once and can accept the new one.

5. Threat model summary

Threat	Mitigation
Internet scanning / opportunistic login attempts	Client certificate; public-address rule; lockout; non-default port; or no open port (VPN).
Password/code guessing	PBKDF2 password + TOTP + lockout (5 tries / 15 min per address).
Eavesdropping on the network	TLS.
Man-in-the-middle	Certificate pinning (compare fingerprint on first connect).
Replay of a captured login	Nonce-bound TOTP proof; TLS.
Stolen settings file	DPAPI-protected secret; certificate requires the profile's private key.
Stolen device	Remove its fingerprint; rotate the TOTP secret.
Compromised PC/laptop OS	Out of scope — no remote-access tool can protect against this.