Docs / Obsidian Remote / Security

How your sessions are protected

Remote-access software opens a door into a PC, so Obsidian Remote is built to keep that door shut to everyone but the people you let in. This chapter explains what protects a session, what your server can and cannot see, and how to tighten things further.

End-to-end encryption

Every session is encrypted between the two PCs themselves (or between the PC and your browser, for the web viewer). The keys are made fresh for each session by the two ends and never leave them. Your server, your network and anyone between them carry only scrambled data, whether the session goes directly across your network or through the server's relay.

In more detail, for the technically minded:

What	How
Each PC's identity	Its own ECDSA P-256 key, made when Obsidian Remote is installed and protected by Windows. The server ties the PC's ID to that key.
Your connection to the server	TLS. With the server's own certificate, the PCs check the server's key from the client config string; with a certificate from a certificate authority, they check it the normal way.
The session keys	A fresh ECDH P-256 key exchange for every session, signed by the remote PC's identity key, so you know you reached the right PC.
The session itself	AES-256-GCM, with a separate key for each direction. Any tampering ends the session.
Passwords	The PC's password never crosses the network. Your PC proves it knows the password with a calculation tied to this one session, which is useless for any other session.
Two-factor codes	Standard 6-digit authenticator codes (TOTP); each code works only once.
Updates	Accepted only when signed with the Integrators Resource release key (see Updates).

The session window's status line says End-to-end encrypted and shows the remote PC's key.

What the server can and cannot see

Your server sees what it needs to introduce PCs and keep a record:

each PC's ID, name, Windows version, signed-in user name, network addresses, and network card address (for Wake-on-LAN),
who connected to which PC, when, for how long, and what kind of session,
how much data the relay carried,
the names and sizes of files transferred, as reported by the PC, for the audit log.

It cannot see the screen, your keystrokes, the clipboard, chat messages, file contents or terminal output, and it never learns a PC's password.

A server that fell into the wrong hands could refuse to connect PCs, push policies to them, or claim a different key for an ID. The Windows app remembers every PC's key and warns you if it ever changes (Device key changed, see Connecting to a computer). The web viewer does the same for the PCs you connected to from that browser (This computer's key has changed).

Protections on each PC

The PC decides who gets in. Whatever the server allows, a viewer still needs the PC's password, or the person at the PC clicking Accept, and a two-factor code if the PC uses it.
One-time passwords change after every session that used them. Permanent passwords are stored only in a form that can check a password but not reveal it.
Limits on guessing: 6 wrong passwords in a minute lock out that address for a minute; 30 in 10 minutes from anywhere pause password sign-ins for 5 minutes. The whole sign-in must finish within 150 seconds, and the PC limits how many people can be signing in at once.
Each kind of session gets only what it needs: a view-only session can never type; a file session can only move files.
Permissions are checked on everything the viewer sends, and the person at the PC can take any permission away at any moment.
Files, the terminal and tunnels respect Windows accounts: files and the terminal work as the signed-in person, with their rights only. With nobody signed in, file transfer and tunnels are refused, and the terminal only works if an administrator explicitly allowed it.
Address and idle limits: the PC can accept viewers only from addresses you name, and end idle sessions.
Direct connections on the network only accept sessions your server set up, unless direct IP access is turned on. LAN discovery only answers PCs on the local network.
On a shared PC, other users can't see the one-time password or answer requests; only the person at the PC's own screen or an administrator can.
Scam protection: the first time someone connects, the person at the PC sees a plain warning about phone scams, Deny comes first and Accept waits 10 seconds; a one-time password typed by someone new needs their Accept too. While someone has control, a bar on top of every screen says so, and Esc pressed twice at the PC's own keyboard ends it at once (keys sent by the viewer don't count). See Letting someone connect.
This PC's data is readable only by the system and administrators, and its secrets are encrypted by Windows.

Protections on the server

Limits on console sign-in attempts and on connection requests; two-factor sign-in for console accounts.
Blocked countries: the server can refuse connections and sign-ins from countries you choose (see The admin console). It also tells the PC the viewer's country for its warning. A server someone else runs - a scammer's own, say - wouldn't, which is why the warnings live in the app.
People who aren't administrators can only reach devices they own or their group's. Address books never give access.
A device ID stays tied to its PC's key (see Devices, users, groups and address books).
A PC can only add audit entries about sessions it was part of.
Relay sessions use single-use tokens that expire within a minute, and idle relayed sessions are closed.
The console and the web viewer run under a strict browser security policy, and the web viewer treats everything a remote PC sends it (names, chat, file names) as plain text, never as code.

What isn't done yet

We'd rather tell you:

The installers aren't code-signed yet, so SmartScreen may warn. Updates are still checked against our signature.
Tunnels on installed PCs connect out under the PC's system account, not as the signed-in person. They are refused while nobody is signed in.
Sessions between different networks always use the relay. They are still end-to-end encrypted, but your server carries the traffic.
The web viewer's "trust this browser" tokens are kept in the browser's storage for your server's site.
Scam protection has limits: a viewer that isn't signed in to your server is recognised by the ID its PC claims; the country is your server's best guess (a VPN changes it); the bar and Esc Esc work on the normal desktop, not on the sign-in or UAC screens.
No outside security audit yet. The code was reviewed in-house before release, and every issue found was fixed.

Hardening checklist

On the server:

Use a certificate from a certificate authority (or nginx with Let's Encrypt), or hand out the client config string only through channels you trust.
Turn on two-factor sign-in for every console account, administrators first, and keep at least two administrators.
Turn on Require sign-in before connecting if only your own people should connect.
Turn off the web viewer if you don't use it.
Open only the server's one port; keep the Linux machine up to date; back up the data folder, which holds data.key.
Read the audit log now and then: failed device passwords, failed console sign-ins and admin actions.

On the PCs, ideally through policies:

Click to accept for staff PCs; Password with Require two-factor for unattended ones (set up two-factor sign-in on each PC first).
Only allow these networks if your technicians always come from known addresses.
Disconnect idle sessions after a sensible time, and Lock this PC when a session ends on unattended PCs.
Untick what you never use: Terminal, TCP tunnels, Restart the computer.
Leave Direct IP access off unless you need it on a network you trust.
Use long, unique permanent passwords.