To prevent TortoiseSVN from saving authentication credentials at the server level, you must configure the Subversion configuration file to disable credential caching. This is achieved by setting the
store-passwords and
store-plaintext-passwords options to
no. This ensures that sensitive data is not persisted on disk, enhancing security for shared or public workstations.
Understanding TortoiseSVN Credential Storage
TortoiseSVN relies on the underlying Subversion client library to handle network operations, including authentication. By default, when you connect to a repository, the client prompts for a username and password. If you check the "Save Authentication" box in the dialog, or if the configuration allows it, the client stores these credentials in an encrypted cache directory on your local machine. While convenient, this practice poses significant security risks, particularly in environments where multiple users access the same computer or where strict compliance with data protection regulations is required.
The configuration files that control this behavior are located in the user's home directory. On Windows, this is typically
%APPDATA%\Subversion\config, while on Linux and macOS, it resides in
~/.subversion/config. Understanding the structure of these files is crucial because they contain global settings that apply to all repositories accessed by that user. Modifying these settings allows administrators or individual users to enforce policies that align with their organization's security standards.
Locating the Configuration File
Before making changes, you need to identify the correct configuration file. TortoiseSVN provides a convenient way to open the folder containing these files directly from the interface. Right-click anywhere in Windows Explorer and select
TortoiseSVN >
Settings. In the settings window, navigate to the
Saved Data category. Here, you will see a button labeled
Open Config Folder. Clicking this button opens the directory where the
config file is stored.
Alternatively, you can manually locate the file using environment variables. For Windows users, the path is usually
C:\Users\\AppData\Roaming\Subversion\config. For Unix-based systems, the path is
~/.subversion/config. It is important to note that there may be two config files: one in the user's home directory and another in the installation directory. Changes made to the user-specific file take precedence over the global installation file, so always edit the one in the user's directory to ensure your settings persist across updates.
Disabling Password Caching via Configuration
The core solution involves editing the
config file to explicitly disable storage mechanisms. Open the file in a plain text editor like Notepad or VS Code. Look for the section titled
Authentication. This section contains several directives related to how the client handles credentials. You need to modify two specific lines:
- store-passwords: This option controls whether passwords are saved in the encrypted keychain or credential store.
- store-plaintext-passwords: This option controls whether passwords are saved in plain text within the configuration file itself.
By default, these are often set to
yes. To prevent saving, change them to
no. The lines should look like this:
# Set this to 'yes' to allow the client to store passwords.
# store-passwords = yes
store-passwords = no
# Set this to 'yes' to allow the client to store plaintext passwords.
# store-plaintext-passwords = yes
store-plaintext-passwords = no
Note that you may need to remove the leading
# character to uncomment these lines if they are commented out by default. After making these changes, save the file. The next time you perform an SVN operation, the client will prompt for credentials but will not offer the option to save them, nor will it automatically reuse previously entered credentials.
Handling Existing Cached Credentials
Changing the configuration does not automatically delete credentials already stored on your system. To ensure complete removal, you must clear the existing cache. Go back to the
TortoiseSVN Settings window and select the
Saved Data category. You will see a list of cached items, including passwords, SSL certificates, and servers. Click the
Clear button next to the
Passwords item. A confirmation dialog will appear; confirm the action to delete all stored credentials. This step is critical because some older versions of the client might still attempt to use old cached entries until they are explicitly purged.
For additional security, you can also restrict access to the configuration file itself. On Windows, right-click the
config file, select
Properties, go to the
Security tab, and ensure that only your user account has read/write permissions. Remove access for other users if necessary. On Linux/macOS, use
chmod 600 ~/.subversion/config to restrict file permissions.
Alternative Methods for Enhanced Security
While disabling password storage is effective, it requires users to enter credentials every time. For environments where automation is needed but security cannot be compromised, consider using SSH keys instead of password authentication. Configure your SVN repository to accept SSH connections and set up key-based authentication. This method eliminates the need for password entry entirely while maintaining strong security through cryptographic keys.
Another approach is to use a dedicated credential manager integrated with your operating system. Tools like KeePassXC or Bitwarden can be configured to auto-fill SVN prompts without storing the data in the Subversion cache. However, this requires additional setup and third-party software. For most organizations, simply disabling the cache via the
config file is the most straightforward and reliable method.
If you are managing a large team, enforcing these settings centrally can be challenging. In such cases, consider deploying group policy objects (GPO) on Windows domains to push the modified
config file to all workstations. This ensures consistent security posture across the organization. For more information on handling authentication issues in different contexts, you might find
Chrome for Android Fails to Autofill Basic HTTP Authentication Passwords useful for understanding broader authentication patterns.
Verifying the Changes
After applying the changes, verify that they are working correctly. Perform an SVN command, such as
svn info or update a working copy. You should be prompted for a username and password. Enter valid credentials. Once the operation completes, try running the same command again. If the configuration is successful, the client should prompt for credentials again rather than using a cached value. If it logs in silently, double-check the
config file syntax and ensure there are no duplicate entries overriding your settings.
Additionally, monitor the
%APPDATA%\Subversion\auth directory (on Windows) or
~/.subversion/auth (on Unix). This directory contains the actual credential caches. With the settings applied, you should notice that new entries are not created, or existing ones are cleared. This visual confirmation helps assure that the security measure is active.
Frequently Asked Questions
Does disabling password storage affect SSL certificate validation?
No, changing the
store-passwords setting only impacts credential caching. SSL certificate preferences are controlled by separate options like
store-ssl-client-cert-ssh. These remain unaffected unless you explicitly modify them.
Can I disable password saving for a specific repository only?
The
config file applies globally to all repositories for a user. There is no built-in per-repository setting to disable password saving. You would need to use separate user accounts or virtual machines for repositories requiring different security levels.
What happens if I forget my password after disabling storage?
Since credentials are not saved, you must remember your password each time. If you forget it, you will need to reset it via the repository administrator or the server's authentication mechanism. TortoiseSVN does not provide a way to recover cached passwords.
Are there any performance benefits to disabling password storage?
There are negligible performance differences. Disabling storage removes the overhead of encrypting and decrypting credentials from disk, but this impact is minimal compared to network latency. The primary benefit is security, not speed.
How do I revert these changes if I want to start saving passwords again?
Simply edit the
config file again and change
store-passwords and
store-plaintext-passwords back to
yes. Save the file, and the next authentication prompt will allow you to save credentials as usual.