Where Does Your SFTP Client Store Your Password?

Your SFTP client knows your server passwords. Where do they go?

If you save a connection in an SFTP client, the application has to keep that secret somewhere. Sometimes that means a protected system store. Sometimes it means a local config file. Sometimes it means a format that looks obscure but is easy to reverse.

That matters because SFTP clients are often used on developer laptops, build machines, shared admin workstations, and support boxes. In those environments, credential storage is not an academic detail. It is the difference between a password being guarded by the operating system and a password being readable from a plain file.

I wanted a simple answer to a simple question: when you save a login in an SFTP client, where does the password end up on disk?

The test setup

For this audit, I compared FileZilla and openSFTP directly, then checked the vendor documentation for Cyberduck and WinSCP for context.

The test pattern was straightforward:

1. Create a saved connection.
2. Inspect the on-disk config files.
3. Check whether the password is stored in plain text, reversible encoding, or a protected system store.
4. Verify whether the application supports a stronger alternative such as SSH keys or a master password.

I also checked source and dependency metadata for openSFTP to see whether it uses a keychain-backed credential library.

FileZilla: passwords in sitemanager.xml

On Linux, FileZilla stores site entries in ~/.config/filezilla/sitemanager.xml. Recent connections can also appear in recentservers.xml.

A typical saved site entry looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<FileZilla3 version="3.66.5" platform="linux">
  <Servers>
    <Server>
      <Host>192.168.1.100</Host>
      <Port>22</Port>
      <Protocol>1</Protocol>
      <Type>0</Type>
      <User>deploy</User>
      <Pass encoding="base64">c3VwZXJzZWNyZXQxMjM=</Pass>
      <Logontype>1</Logontype>
      <Name>Production Server</Name>
    </Server>
  </Servers>
</FileZilla3>

That Pass value is not encrypted. It is base64.

Decoded, the test value becomes:

supersecret123

That is the key thing to understand. Base64 is an encoding, not protection. Anyone who can read the file can decode it in seconds.

The same pattern appears in recentservers.xml for recently used servers. If the client stores a recent login with credentials, the password is again represented in reversible form.

What that means in practice

Base64 storage is not the same as keeping a password in clear text, but it is also not real security.

If an attacker or a local process can read the config directory, the secret is effectively exposed. That includes:

• malware running as the same user
• backup tools that copy home directories
• support scripts that collect config files
• accidental uploads of dotfiles to issue trackers or archives
• forensic access after a machine is compromised

So the honest summary is this:

• FileZilla does store saved passwords on disk
• the default format is reversible
• without the optional master password, it is not protected by strong encryption

FileZilla master password: real feature, not default behavior

FileZilla does have a master password feature. That matters, because it means the product is not simply “insecure by design.”

The issue is default behavior.

A master password can protect stored credentials with stronger cryptography, but it has to be enabled by the user. In other words, FileZilla can be configured to protect saved passwords, but many installations never turn that on.

That distinction is important for a security audit:

• the capability exists
• the safer mode is available
• the default path is still weak

If you use FileZilla and save passwords, the safest move is to enable the master password or, better yet, avoid password storage entirely and use SSH keys.

openSFTP: connections without stored passwords

openSFTP takes a different approach.

The connection metadata lives in ~/.config/sftp-ui/connections.json, but the file does not contain the password itself.

A saved connection looks roughly like this:

[
  {
    "id": "prod-1",
    "name": "Production Server",
    "host": "192.168.1.100",
    "port": 22,
    "username": "deploy",
    "auth_method": "password",
    "favorite": true
  }
]

There is no password field in that file.

That is the important part. The config file stores the connection identity and preferences, not the secret. According to the project metadata, openSFTP depends on keyring, which is the standard Python library for integrating with OS-backed secret storage.

The dependency list includes:

PySide6>=6.5
paramiko>=3.0
keyring>=24.0

And the client code shows that authentication secrets are passed into the SSH layer at connect time, not embedded in the persistent connection JSON.

From a security perspective, that is a cleaner model:

• the visible config file stays non-sensitive
• the secret can live in the OS credential store
• the application does not need to duplicate secret handling in a custom file format

That does not make the app magically immune to compromise. If your user session is compromised, a local attacker may still be able to access secrets through the account context. But it is materially better than leaving credentials in a readable app config file.

Cyberduck: system keychain backed storage

Cyberduck’s documentation says its preferences are stored separately from bookmarks, history, and connection profiles. More importantly for this article, Cyberduck is designed around the operating system’s secret storage rather than a custom file full of passwords.

On macOS, that means the Keychain. On Windows, it uses the platform equivalent where applicable.

The practical security advantage is simple:

• passwords are not usually kept in a human-readable app config file
• the OS handles access control and encryption at rest
• the client reads secrets when needed instead of serializing them into its own config format

Cyberduck is still a client that can remember credentials, so it is not “password free.” But its storage model is much closer to what you want from a desktop tool in 2026.

WinSCP: encrypted with a master password, but not always protected

WinSCP is the most nuanced of the group.

Its documentation says stored passwords are protected with strong AES encryption when a master password is set. It also says that without a master password, stored passwords can be easily decrypted by malware on the computer.

That is a very direct admission, and it is useful because it separates capability from configuration.

WinSCP can do the right thing:

• use AES for stored passwords
• protect sessions with a master password
• keep the secret harder to extract from disk

But if the user does not set the master password, the saved credentials are not really protected in a meaningful way.

So the comparison looks like this:

• WinSCP is better than plain reversible storage when configured correctly
• WinSCP is weaker when left at defaults
• the master password is the deciding factor

SSH keys are still the better answer

Across all of these clients, the cleanest answer is not “choose the best password vault.” The cleanest answer is to stop storing reusable passwords where possible.

Use SSH keys instead.

Why keys win:

• they are not the same as a reusable login password
• they can be protected by a local passphrase
• the private key can live in a file or hardware-backed store
• revocation is simpler and scope is narrower
• many clients support agent-based workflows that reduce secret exposure

In the openSFTP codebase, authentication is handled through Paramiko, which supports key-based SSH authentication alongside password auth. That matters because it means the client can work well in the safer mode, not just the convenience mode.

Permissions still matter

Even when a client stores data responsibly, file permissions are part of the picture.

A few defaults are worth checking:

• ~/.config/filezilla/sitemanager.xml
• ~/.config/filezilla/recentservers.xml
• ~/.config/sftp-ui/connections.json

If those files are readable by the user, then any process running as that user can usually read them too. That is normal Unix behavior, not a bug.

The question is what the file contains.

If the file contains a reversible password blob, your exposure is much higher. If the file contains only non-sensitive metadata, the risk is much lower. If the secret lives in the system keychain, exposure depends on the OS security model instead of a custom app format.

That is why the storage model matters more than the directory name.

Quick comparison

Client	Where passwords end up	Default protection	Notes
FileZilla	sitemanager.xml, also recentservers.xml	Weak	Passwords are stored as reversible base64 unless a master password is used
openSFTP	Not in connections.json	Better	Connection metadata stays in JSON, secrets are handled separately via keyring-backed storage
Cyberduck	System keychain and app support storage	Stronger	Uses OS credential storage instead of a custom visible password file
WinSCP	Config-backed sessions	Depends	AES protection is available, but only with a master password

What to do if you use FileZilla

If your team uses FileZilla, do not treat the default storage model as safe just because it is not plain text.

Recommended actions:

1. Enable the master password.
2. Prefer SSH keys over passwords.
3. Do not keep long-lived credentials in shared backups.
4. Review sitemanager.xml and recentservers.xml on developer machines.
5. If a laptop is lost or compromised, assume saved credentials may be exposed unless they were protected.

The base64 detail is the key takeaway for readers. It is easy to miss because the file does not look like a plaintext password list at first glance. But reversible storage is still reversible storage.

What to do if you build or choose an SFTP client

If you are evaluating SFTP software for a team, ask these questions before you ship it:

• Does the client store passwords in a plain file?
• Does it rely on base64 or another reversible encoding?
• Does it support the OS keychain or equivalent?
• Is the safer mode enabled by default?
• Can users choose SSH keys without friction?
• Are credentials split from ordinary config data?

Those questions are more important than a feature checklist.

A polished UI does not make weak secret handling safe. A modern app can still leak passwords if it writes them into a file that every backup script can copy.

FAQ

Is base64 encryption?

No. Base64 is reversible encoding. Anyone can decode it.

Does FileZilla have a master password?

Yes. FileZilla supports an optional master password, but it is not enabled by default.

Does openSFTP store passwords in its JSON config?

Not in the connection file itself. The connection JSON stores metadata such as host, port, username, and auth mode, while secrets are handled separately through keyring-backed storage.

Is the system keychain always safe?

No storage layer is perfect. But the system keychain is generally a better place for secrets than a custom file in a user config directory.

Are SSH keys always better than passwords?

For SFTP and SSH use cases, yes in practice. They reduce password reuse and make storage and rotation easier to manage.

Bottom line

If you save passwords in your SFTP client, check the storage model before you trust it.

FileZilla keeps saved credentials in sitemanager.xml and recentservers.xml using reversible base64 unless you enable its optional master password. openSFTP keeps the connection file free of passwords and relies on keyring-backed storage instead. Cyberduck leans on the system keychain. WinSCP can encrypt stored passwords with a master password, but only if you actually set one.

So the answer to the title question is not the same for every client.

Some store passwords in a readable config path with reversible encoding. Some store them in the operating system’s secret store. Some can do both, depending on configuration.

If you want the short recommendation, it is this:

• prefer SSH keys
• prefer keychain-backed storage over app-owned secret files
• do not assume “not plain text” means “secure”
• enable stronger protection where the client offers it

For a desktop SFTP client, secret handling should be boring. If you have to inspect XML just to understand where your password lives, that is already a sign to look harder.