The short version
- Passwords live in one encrypted file, the vault. Without your master password the file is unreadable.
- Your master password is never stored anywhere. Forget it and the vault cannot be opened, by you or by anyone else. There is no recovery.
- PuTTY's saved sessions hold only the name of a vault entry, never a password.
- A password leaves the vault only to log you in, or when you ask (reveal, copy, edit, export).
- While the vault is unlocked, anything running as your user on your computer could in principle reach it. Lock it when you step away.
The vault file
| Where | vault.bin in Thyrion's data folder: ~/.local/share/com.thyrion.desktop/ on Linux, %APPDATA%\com.thyrion.desktop\ on Windows. |
|---|---|
| Encryption | AES-256-GCM. The file's header (format version and key settings) is authenticated too, so a changed header is rejected. |
| Key | Derived from your master password with Argon2id: 64 MiB of memory, 3 passes, a random 16-byte salt per vault. This makes guessing master passwords slow, even with the file in hand. |
| Each save | Encrypted again with a fresh random nonce, written to a new file and swapped in, so a crash can't leave half a vault. |
| Permissions | Readable by your user only (on Linux, 600, set when the file is created). |
A vault file that asks for key settings far beyond Thyrion's own (for example a damaged or altered file) is refused before any work is done.
Locking and unlocking
- Unlocking turns your master password into the key and decrypts the vault into memory. The master password itself is not kept.
- Locking (the lock button, or closing Thyrion) erases the key and every decrypted password from memory.
- The vault stays unlocked until you lock it or close Thyrion. There is no automatic lock after a period of inactivity yet.
- Deleting the vault (in Settings) asks for confirmation; it removes the file for good.
When a password leaves the vault
Logging in to an SSH session
PuTTY's plink reads a login password from a file, not from its command line (where other programs could see it). Thyrion writes the password to a temporary file readable only by your user, starts plink, and deletes the file 5 seconds later; plink has read it within milliseconds. If Thyrion is killed in those seconds, the file is deleted the next time Thyrion starts. The SFTP browser does the same for psftp.
The password is briefly on disk in your temporary folder in this way. On an encrypted disk (BitLocker, LUKS) that is covered by the disk encryption.
Jump hosts
- Through a jump host (tunnel): Thyrion logs in to the jump host with its password; the connection to the device behind it runs encrypted through the jump host, so the jump host never sees the second password.
- Through a device's command line: Thyrion types the second device's
sshortelnetcommand and its password into the first device. The first device therefore sees that password. That is how the method works (it's the same as typing it yourself); use it only through devices you trust.
Thyrion answers only its own steps, in order, and stops if a password is refused or a step fails, so it never retries a stored password.
Enable passwords
With "send the enable password" on for a session, Thyrion types it only when you have just typed enable (or en, super) yourself, within the last 5 seconds, and the device answers Password:. What you typed is read from your keystrokes, not from what the device prints, so a device cannot fake it. An enable prompt is never answered with the login password.
Automatic console login (telnet and serial)
With "log in automatically" on, Thyrion answers the console's Username: and Password: prompts once per connection. It stops as soon as you run a command, so a password prompt from something you started (for example ssh from the console to another host) never gets the console's password.
"Send password" and copying
- Send password types the password straight into the session from Thyrion's core; it never passes through the window's interface.
- Copy password puts it on the clipboard and clears the clipboard after 25 seconds if it still holds that password. A clipboard manager may keep its own copy; Thyrion can't prevent that.
- Reveal and edit in the Vault screen show the password in the window while you are looking at it.
Export to KeePass (.kdbx)
The export asks for your master password and protects the .kdbx file with it. The file is written readable by your user only. Once exported, it is protected by the KeePass format and the password you chose, not by Thyrion.
What Thyrion does not protect against
- Malware running as your user while the vault is unlocked: it could read Thyrion's memory, your keystrokes or your clipboard. No password manager can stop that; keep your computer clean and lock the vault when away.
- A weak master password. Argon2id slows guessing down; it can't make a short or common password strong. Use a long passphrase.
- The devices you connect to. A password typed into a device can be logged or seen by whoever controls that device. Session logs record what a device prints; devices normally don't print passwords, but some echo them back.
- Forgetting the master password. There is no recovery and no back door. Export to KeePass from time to time if you want a backup.
Privacy
Thyrion connects only to the hosts you open sessions to. It sends nothing anywhere else unless you ask it to.
Code signing
Windows releases are to be signed through SignPath's program for open-source projects, from the first release after the project is accepted. Free code signing provided by SignPath.io, certificate by SignPath Foundation.
- Every release is built from the public repository by GitHub Actions (release.yml); nothing built anywhere else is signed.
- Committers, reviewers and approvers: ArisAlt. Each signing request is approved by hand.
Reporting a vulnerability
Please report privately, not in a public issue. Anything that could expose passwords or keys counts.
- Open the repository's private vulnerability report form (Security tab → Report a vulnerability).
- Describe what an attacker could do, and how to reproduce it. Use placeholder hosts (
192.0.2.10) and never include real passwords.
If that page isn't available, open an issue titled "Security contact" with no details, and the maintainer will get in touch to take the report privately. Expect a first reply within a week. Fixes go out in a new release, and the report is credited in its notes unless you'd rather not.
Only the latest release gets security fixes, so please update before reporting.
In scope
- The password vault and anything that could reveal its contents
- Automatic logins: SSH, jump hosts, enable passwords, console login
- Anything that lets a remote device, a session's output or a file make Thyrion run commands or send input it shouldn't
- Saved sessions, logs, exports and temporary files
Out of scope
- Problems in PuTTY itself: report those to PuTTY's authors.
- Attacks that need malware already running as your user, or physical access to an unlocked computer with the vault unlocked.
The full, authoritative version of this page is docs/PASSWORDS.md in the source repository.