Overview

RustDesk authorization begins after transport trust and treats access as more than a password. A fresh connection challenge supports password verification, while temporary or permanent passwords, local approval, TOTP, remembered devices, and failure controls provide different evidence and states. After primary approval, the original login type and scope are latched, intersected with local settings, and translated into subscriptions for display, input, files, terminal, tunnels, privacy, and other services. The model limits accidental privilege changes, but endpoint operating-system privileges and policy still bound what it can enforce.

Learning outcomes

RustDesk’s challenge-bound password check authenticates a connection attempt, but a weak password remains weak and storage encryption is not remote authentication.
Approval, passwords, TOTP, remembered devices, and rate limits provide different evidence and failure states rather than one interchangeable login.
The original session type is latched and intersected with local permissions, so authorized connections subscribe only to allowed services; endpoint privileges still matter.

Keywords

RustDeskauthorizationscopepermissionspasswordsTOTP

A Connection Is Not a Permission

RustDesk's previous connection stages can produce an encrypted, peer-bound channel, but that channel is not yet permission to operate the machine. This chapter examines the authorization lifecycle that follows transport trust: per-connection challenge, approval mode, passwords, two-factor authentication, remembered devices, failure limits, and capability scope. The practical judgment is whether a session has merely arrived at an endpoint or has actually been allowed to perform a particular kind of work there.

Authorization starts after the route

RustDesk creates a fresh challenge for an incoming connection using an effective password salt and a generated value. The controller's password is not simply treated as a message that the endpoint compares in the clear. The endpoint derives a challenge-bound value and compares it in constant time. The purpose is twofold: the challenge ties the check to this connection, and the comparison avoids making the number of matching leading bytes an obvious timing signal. Neither measure makes a weak password strong, but each addresses a different part of the authentication problem.

The project supports several primary approval arrangements because “the user has connected” can mean different things operationally. A controlled endpoint may require a temporary password, a permanent password, a click from a local user, or a combination of approval and password. The temporary password is useful for a session that should not depend on a long-lived secret; the permanent password is useful for unattended access. Click approval offers a human decision at the endpoint. These paths are related, but they are not interchangeable evidence: a password proves possession of a secret, while a click proves that someone at the endpoint approved the request at that moment.

The storage path for a permanent password is also separate from the network handshake. The repository supports salted password-derived material, encrypted local storage, and compatibility paths, while rejecting malformed current-format storage rather than treating an unusable value as a valid legacy password. The local encryption of a configuration value protects a stored secret or hash against some forms of casual inspection; it does not itself authenticate a remote controller. Authentication happens when the presented value is checked against the active connection challenge and the endpoint's effective policy.

Two-factor authentication adds another state rather than replacing the primary one. When TOTP is enabled, the endpoint can keep the connection alive while it waits for the second factor. A correct code completes that step; a wrong code is subject to failure handling. The project can also remember a trusted device, but that shortcut is conditional. The stored device must still be current and must match the expected peer identity, name, platform, and hardware identifier. “Trusted device” therefore means a bounded remembered relationship, not a universal bypass for anyone who knows the endpoint ID.

Recent sessions serve a related but different purpose. The endpoint can retain a short-lived session record and use it when the same peer reconnects under the expected conditions. That reduces friction without making the record permanent.

Published by DeepMox

FAQ

How does RustDesk verify a connection password?

RustDesk combines the presented password with a fresh connection challenge and compares the derived value in constant time; this does not make a weak password strong.

What does RustDesk two-factor authentication add?

TOTP adds a second approval state after the primary check, while wrong codes remain subject to failure handling; it does not replace the primary policy.

Why does RustDesk latch the original login scope?

It prevents authentication retries from changing a pending request, such as turning file transfer into terminal access, while local settings still limit the final services.

Previous7 minRustDesk Session Diagnosis: Reachability to Trust

Next10 minRustDesk Remote Services: Usable and Bounded

RustDesk Authorization: Login to Scope

A Connection Is Not a Permission

Authorization starts after the route

FAQ