Skip to content
telnety

Security

How Telnety protects your servers, credentials, and identity.

The short version

Telnety is a remote-management tool used by sysadmins and DevOps engineers. Everything in our design defaults to least privilege, fail-closed, and visible by inspection. We encrypt locally, sign what we ship, and refuse to silently downgrade trust. The sections below describe the controls in detail.

Encrypted credential vault

Every password, SSH key, and RDP credential is encrypted at rest with AES-256-GCM. Encryption keys are derived from your master password with Argon2id (m=64 MiB, t=3, p=4) and a per-entry salt, so two identical passwords never produce the same ciphertext on disk.

Zero-knowledge architecture

Vault contents are encrypted on-device before sync. The Telnety server stores ciphertext only — we never see, log, or back up plaintext credentials. Losing your master password means losing access to that vault entry; we cannot reset it for you.

Account hardening

Passwords are hashed with bcrypt at cost 12. Refresh tokens are stored as SHA-256 digests, never as plaintext. Failed login attempts are tracked and accounts lock after 5 failures in 15 minutes. All auth endpoints are rate-limited.

Transport security

Every connection to telnety.com, app.telnety.com, admin.telnety.com, and api.telnety.com is served over TLS 1.3 with HSTS preloading. The dashboard and admin portals ship a strict Content-Security-Policy with per-request nonces.

Trust-on-first-use SSH

The first time you connect to an SSH host, Telnety pins its host key. If that key ever changes, the desktop and Android clients refuse the connection and surface a red warning — we never auto-accept a new key on your behalf. This is non-negotiable.

Signed license blobs

License blobs are signed with Ed25519 on the server and verified on-device. Tampering with a license file invalidates the signature; the desktop and mobile clients fall back to Community features rather than trusting a broken blob.

Cryptography in detail

  • Vault: AES-256-GCM with random 96-bit nonces and per-entry salt. Argon2id derives the master key.
  • Passwords: bcrypt cost factor 12 (~250 ms/hash on modern hardware).
  • Refresh tokens: SHA-256 digest in the database, raw token only in the client cookie.
  • License signing: Ed25519 with the public key embedded in every desktop and Android build.
  • SSH host keys: pinned on first use, blocked on change.
  • Webhooks: Paddle webhooks are verified by HMAC-SHA256 (the Paddle-Signature header) before any state change.

Data we collect

We collect the minimum needed to run the service: your email, account profile, subscription state, license activations (device fingerprint + last-seen timestamp), and aggregated product analytics. We do not collect, transmit, or store the contents of your remote sessions, the credentials in your vault, or the files you transfer over SFTP.

See the privacy policy for the legal version.

Responsible disclosure

If you believe you have found a vulnerability in Telnety, please write to with a description, reproduction steps, and your preferred contact channel. We confirm receipt within 48 hours and aim to ship a fix or mitigation within 14 days for severe issues.

Please give us a reasonable window to remediate before public disclosure. We do not yet run a paid bounty program, but we credit researchers in our changelog on request.

Compliance roadmap

Telnety is operated by ANUBRIS (Private) Limited. We are not currently SOC 2 or ISO 27001 certified. Both are on the roadmap for the year after v1.0 ships and team plans reach meaningful adoption. Customers on regulated workloads should choose the Business plan, which includes on-prem deployment and a custom DPA.