Security

What is protected, how, and what you should do yourself.

In short

Every session is encrypted between the two computers. A server or relay in the middle passes the data along but cannot read it or change it.
A password is never sent over the network, and a wrong guess reveals nothing that helps the next guess.
Your server decides who may connect to enrolled devices, and each device checks the server's decision itself.

How a session is protected

The two computers exchange a short greeting that says which version and sign-in methods they support.
With a password: they run SPAKE2, a password-authenticated key exchange. Both sides prove they know the password without revealing it. Someone listening, or a server in the middle, gets one guess per connection attempt and nothing to test guesses against later.
With server access: the server issues a signed ticket naming the user, the device, the access level and the controller's key, valid for two minutes. The device checks the signature against the server key it stored when it enrolled, and checks that the ticket belongs to the computer presenting it.
They then run the Noise protocol (Noise_XX, or Noise_XXpsk3 when a password is used, with X25519, ChaCha20-Poly1305 and BLAKE2s) to agree on session keys. The greeting from step 1 is bound into this step, so it cannot be altered in transit.

Hover over the lock in the session toolbar to see the remote computer's key fingerprint. The same fingerprint is shown on that computer under Settings → This device.

Passwords and guessing

Item	Protection
One-time password	8 random characters, replaced after each session that used it, and on demand with the refresh button.
Permanent password	Stored only as an Argon2 key derived from it.
Direct connections	After 5 wrong passwords from one address within a minute, that address is refused for a while.
Dashboard sign-in	Passwords are stored as Argon2id hashes. After 5 failed attempts for a user from one address, sign-in is blocked for 5 minutes. Optional two-factor codes.
Sign-in sessions	Last 7 days. The server stores only a hash of each session token.

What the server can and cannot do

It can see which devices exist, when they are online, their system information, and who connected to what and when.
It can authorise a user to connect to an enrolled device, at the level an administrator granted.
It cannot see or alter the screen, keystrokes, files, clipboard or chat of a session.

Because the server authorises access, whoever controls an administrator account or the server's data folder can grant themselves access to enrolled devices. Protect the server accordingly.

What you should do

Serve the dashboard over HTTPS.
Create the first administrator immediately after installing, and turn on two-factor sign-in for administrators.
Back up server.key with the database and keep both private.
Give installers an expiry and a limit, and revoke them when you are done.
Grant View only or Control rather than Manage unless someone needs to manage devices.
Use a long permanent password for unattended access, or none at all if you use server access.
Expose the direct-connection port (21420) to the internet only if you need it. Inside a network or VPN it is fine.

On the computer itself

Any program running on the same computer can read the current one-time password and end sessions through Humble's local control port (21421, reachable only from the computer itself). This is the same information the Humble window shows on screen.
On Linux with Wayland, Humble creates virtual input devices. The installed rule allows this only for the user logged in at the machine.
A session with Control access can read and write any file the background service can. On Windows the service runs as the system account.

Reporting a problem

If you find a security problem, report it privately to the maintainers of the repository rather than in a public issue.