Security at TConnect

🔐 Your vault is encrypted with a key we never see in the clear

Every saved server credential — password, private key, passphrase — is encrypted with AES-256-GCM, using a key derived per-user with scrypt (N=16384, r=8, p=1) from your login password and a random salt. That key exists only in server memory while you're logged in; it's never written to disk. Log out, restart the server, or an attacker gets a copy of the database — none of it decrypts without your password.

Your login password itself is never stored. It's hashed with scrypt and a random 16-byte salt, and compared with a fixed-time comparison so a timing attack can't be used to guess it byte-by-byte.

Changing your password isn't cosmetic. It re-derives the encryption key and re-encrypts every stored secret — every server password, every SSH key, your 2FA seed, your passkey-unlock wrapper — under the new key, then revokes every other active session. Most tools let you change a password without touching what it protects. This one doesn't, because a password change that leaves the old key valid everywhere isn't a real password change.

🔑 Getting in requires more than a password

🛡 Every credential compromise is contained, not catastrophic

This is the part most tools skip: known-hosts pinning (TOFU). The first time you connect to a server, TConnect pins its SSH host key fingerprint. If that fingerprint ever changes on a later connection — the signature of a man-in-the-middle attack or a compromised server — the connection is refused outright, not just flagged.

Session sharing links expire automatically (6 hours), and every sensitive action — logins, failed logins, password changes, vault exports, admin changes — writes to an audit log with the acting user and source IP.

🌐 The network tools don't become an attack surface against you

When we added sysadmin utilities (port scanner, SSL checker, HTTP header inspector), we found — and fixed — the obvious failure mode before shipping: any of those tools could be pointed at internal infrastructure instead of the public internet. If TConnect runs alongside other private services on the same network, an unrestricted "scan any host" tool is a lateral-movement bridge into them.

Every network-facing tool now resolves the target hostname and rejects private, loopback, link-local, and cloud-metadata address ranges (10.0.0.0/8, 127.0.0.0/8, 169.254.169.254, etc.) — checked against the resolved IP, not the literal input, so a hostname engineered to resolve to an internal address (DNS rebinding) can't slip past the filter either. Verified against real internal targets before deployment, not assumed safe.

🔒 Locked down at the transport layer

• Content-Security-Policy restricting scripts/styles to self and one pinned CDN — blocks injected script execution even if an XSS bug existed elsewhere.
• X-Frame-Options: DENY — the app can't be iframed and clickjacked.
• HSTS (1 year, includes subdomains) once TLS is on — browsers refuse to ever downgrade to plain HTTP.
• Permissions-Policy disabling camera, microphone, geolocation, USB, and payment APIs the app has no legitimate reason to touch.
• Cross-Origin-Opener-Policy / Resource-Policy: same-origin — closes cross-origin data-leak side channels.