Many servers are configured to require authentication on
every request. This would be a big annoyance to users if
they were forced to type their passwords over and over again.
Fortunately, the Subversion client has a remedy for
this—a built-in system for caching authentication
credentials on disk. By default, whenever the command-line
client successfully responds to a server's authentication
challenge, it saves the credentials in the user's private
runtime configuration area
~/.subversion/auth/ on Unix-like systems
%APPDATA%/Subversion/auth/ on Windows;
see the section called “Runtime Configuration Area” for more details
about the runtime configuration system). Successful
credentials are cached on disk and keyed on a combination of the
server's hostname, port, and authentication realm.
When the client receives an authentication challenge, it first looks for the appropriate credentials in the user's disk cache. If seemingly suitable credentials are not present, or if the cached credentials ultimately fail to authenticate, then the client will, by default, fall back to prompting the user for the necessary information.
The security-conscious reader will suspect immediately that there is reason for concern here. “Caching passwords on disk? That's terrible! You should never do that!”
The Subversion developers recognize the legitimacy of such concerns, and so Subversion works with available mechanisms provided by the operating system and environment to try to minimize the risk of leaking this information. Here's a breakdown of what this means for users on the most common platforms:
On Windows 2000 and later, the Subversion client uses standard Windows cryptography services to encrypt the password on disk. Because the encryption key is managed by Windows and is tied to the user's own login credentials, only the user can decrypt the cached password. (Note that if the user's Windows account password is reset by an administrator, all of the cached passwords become undecipherable. The Subversion client will behave as if they don't exist, prompting for passwords when required.)
Similarly, on Mac OS X, the Subversion client stores all repository passwords in the login keyring (managed by the Keychain service), which is protected by the user's account password. User preference settings can impose additional policies, such as requiring the user's account password be entered each time the Subversion password is used.
For other Unix-like operating systems, no standard
“keychain” services exist. However,
auth/ caching area is still
permission-protected so that only the user (owner) can
read data from it, not the world at large. The operating
system's own file permissions protect the passwords.
Of course, for the truly paranoid, none of these mechanisms meets the test of perfection. So for those folks willing to sacrifice convenience for the ultimate security, Subversion provides various ways of disabling its credentials caching system altogether.
To disable caching for a single command, pass the
$ svn commit -F log_msg.txt --no-auth-cache Authentication realm: <svn://host.example.com:3690> example realm Username: joe Password for 'joe': Adding newfile Transmitting file data . Committed revision 2324. # password was not cached, so a second commit still prompts us $ svn delete newfile $ svn commit -F new_msg.txt Authentication realm: <svn://host.example.com:3690> example realm Username: joe …
Or, if you want to disable credential caching permanently,
you can edit the
config file in your
runtime configuration area and set the
store-auth-creds option to
no. This will prevent the storing of
credentials used in any Subversion interactions you perform on
the affected computer. This can be extended to cover all
users on the computer, too, by modifying the system-wide
runtime configuration area (described in the section called “Configuration Area Layout”).
[auth] store-auth-creds = no
Sometimes users will want to remove specific credentials
from the disk cache. To do this, you need to navigate into
auth/ area and manually delete the
appropriate cache file. Credentials are cached in individual
files; if you look inside each file, you will see keys and
svn:realmstring key describes
the particular server realm that the file is associated
$ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 joe K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domain.com:443> Joe's repository END
Once you have located the proper cache file, just delete it.
One last word about svn's
authentication behavior, specifically regarding the
options. Many client subcommands accept these options, but it
is important to understand using these options does
not automatically send credentials to the
server. As discussed earlier, the server “pulls”
credentials from the client when it deems necessary; the
client cannot “push” them at will. If a username
and/or password are passed as options, they will only be
presented to the server if the server requests them. These
options are typically used to authenticate as a different user
than Subversion would have chosen by default (such as your
system login name) or when trying to avoid interactive
prompting (such as when calling svn from a
A common mistake is to misconfigure a server so
that it never issues an authentication challenge. When
--password options to the client, they're
surprised to see that they're never used; i.e., new
revisions still appear to have been committed
Here is a final summary that describes how a Subversion client behaves when it receives an authentication challenge.
First, the client checks whether the user specified
any credentials as command-line options
--password). If so, the client will try
to use those credentials to authenticate against the
If no command-line credentials were provided, or the
provided ones were invalid, the client looks up the server's
hostname, port, and realm in the runtime configuration's
auth/ area, to see if appropriate
credentials are cached there. If so, it attempts to use
those credentials to authenticate.
Finally, if the previous mechanisms failed to
successfully authenticate the user against the server, the
client resorts to interactively prompting the user for
valid credentials (unless instructed not to do so via the
--non-interactive option or its
If the client successfully authenticates by any of these methods, it will attempt to cache the credentials on disk (unless the user has disabled this behavior, as mentioned earlier).