EncryptedPasswordStorage

This page documents the support provided by the Subversion client layer for caching user credentials in a cryptographically safe fashion, and provides a workspace for contributions regarding how that support can be expanded and simplified for more widespread general use.

What's Offered Today

The Subversion core libraries handle credential caching (and automatic recall) using a variety of mechanisms. Most of those mechanisms are not implemented by the Subversion codebase itself, but are offered as services by the operating system or third-party security libraries/subsystems. In fact, Subversion's codebase offers but a single general type of credential caching: plaintext storage using flat files created in the user's runtime configuration area (under $HOME/.subversion/auth/ on Unix platforms; under %APPDATA%/Subversion/auth/ in Windows).

For many users, this solution is secure enough because, for instance, there is but a single user on their machine, or there are several users with their own home directories whose filesystem-level permissions don't permit one user to access and read another user's credential caching files. But some Subversion-using companies desire more in terms of password caching. So Subversion also integrates with several other types of external storage mechanisms.

Generally speaking, the extent of this integration is to continue to store in the runtime configuration area's auth/ subdirectory the same information which is stored there when plaintext password caching is in use, with one key difference. Instead of a "password" record in the file associated with a particular server realm, there is a "passtype" record which tells Subversion where to look for the real password. The following subsections describe the various stores which Subversion can use to hold those real passwords.

Windows Cryptographic Services

Subversion running on Windows 2000 or newer will use Windows' standard cryptographic services to encrypt credentials before caching them on disk. This subsystem of the operating system ties the cryptographic algorithm to the user's system login credentials, allowing the user to read and write encrypted credentials without additional prompting or challenges after the initial login mechanism.

Mac OS X Keychain

On Mac OS X, Subversion stores passwords in the login keyring (which is managed by the Keychain service). Similarly to the Windows situation, this keychain is protected by the user's account password. The Keychain service allows users to impose additional policies, too, such as requiring that the user's account password be entered each time the Subversion password is used.

GNOME Keyring and KDE Wallet

Many Unix systems provide either the GNOME or KDE graphical windowing environments, both of which offer services similar to the Mac OS X Keychain. Generally speaking, these password managers offer one or more keychains, which each keychain encrypted by some passphrase. Users must first unlock the keychains with the passphrase before applications can read and write from the keychains.

GNOME Keyring offers a small improvement here in that it can automatically create a default login keychain and use the user's login password as the passphrase for that keychain. This allows a single-sign-on sort of behavior (the same way that Mac OS X Keychain and the Windows Cryptographic Services work). KDE Wallet has not yet implemented similar behavior (see http://techbase.kde.org/Projects/Utils/kwallet/FeaturePlan42). Subversion 1.6 and newer allows users to optionally store their passwords in these services. One downside of these services is that they often aren't installed on headless machines – computers which are only accessed via remote login and for command-line usage only.

GPG Agent

Subversion's 1.8-dev codebase currently offers an integration with GPG Agent, which is yet another third-party cryptographic service provider. That said, Subversion's use of this agent is not such that encryption takes place at all – the GPG Agent serves simply as an in-memory cache of plaintext passwords for Subversion's purposes. See the "SECURITY CONSIDERATIONS" comment here: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/gpg_agent.c?annotate=1151069#l39

Concerns/Complaints

Subversion today doesn't force users to employ an encrypted storage mechanism for cached credentials. It will at least prompt users before caching a password in plaintext, but if the answer is "no", then generally no caching happens at all. There are a number of runtime configuration gyrations which users can make to toggle related behaviors: which keychain services to attempt to use, whether passwords should be stored in plaintext or not ... or at all, etc. But enterprise Subversion administrators are looking for something more turn-key. Ideally, the decision to store passwords in plaintext should be taken out of the users' hands altogether (such as is the case in Windows and Mac OS X), but at what cost? At the cost of not caching credentials at all? At the cost of requiring custom-built Unix Subversion client binaries with hard-coded encryption key "magic"? At the cost of a hard requirement on one of the third-party crypto keychain providers?

Improvements We Could Explore

Built-in Encryption with a Master Passphrase

Subversion could employ built-in encryption protected by a master passphrase.

Per-site Password Caching Options

Using the web browsers again as an example, Subversion could ask before storing any not-currently-cached user-provided credentials and look for one of the following three responses: "yes", "no", or "never". A response of "never" is recorded by using a special "passtype" record value ("nocache" or somesuch) in the auth/ runtime configuration area, and can be used in the future to avoid prompting the user about caching for that particular realmstring.