subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "MasterPassphrase" by CMichaelPilato
Date Tue, 13 Mar 2012 13:57:39 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "MasterPassphrase" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/MasterPassphrase

New page:
= Master Passphrase Support =

Like all popular web browsers, [[http://www.mozilla.org/en-US/firefox/fx/|Mozilla Firefox]]
allows you to optionally cache passwords used for site logins. Site credentials are cached
on disk, and in plaintext by default. However, Firefox allows you to optionally configure
a "Master Password". This password (or passphrase) is used to encrypt the on-disk cached site
credentials, functioning effectively the same way that a keyring provider and associated passphrase
would work. Firefox will challenge the user for the master password the first time it needs
to consult its credentials cache, and will leave the cache "unlocked" for the duration of
the application's lifetime. (Reference: http://luxsci.com/blog/master-password-encryption-in-firefox-and-thunderbird.html)

Subversion should be able to do something similar, allowing users to optionally employ a master
passphrase which is used to encrypt and decrypt other sensitive information stored in its
[[EncryptedPasswordStorage|authentication credential cache(s)]].  Long-lived Subversion GUI
clients could query the user for his or her master passphrase the first time the local credential
cache is consulted, and remember that passphrase for the lifetime of the application, just
like Firefox does.

But what about the relatively short-lived command-client?  Obviously, if naively implemented,
a user would need to provide the master passphrase as often as they would their actual repository
credentials if caching was not available at all. This would render the credential cache useful
only insomuch as it reduces the potentially boundless amount of site credentials the user
must memorize to a single item:  the master password itself.

Fortunately, both the command-line client and GUI clients can benefit from existing integrations
with encrypted stores on the various operating systems.  On Windows, command-line clients
and GUI clients alike needn't query for the master passphrase once that passphrase itself
has been cached using Windows Cryptographic Services.  Similar is true on Mac OS X using the
Keychain.  Essentially, any existing keystore integration which today can be used to store
a bunch of passwords could instead be used to store just a single master passphrase.

== Benefits ==

 * Centralization:  Rather than spread repository credentials cross a variety of stores (on-disk,
keystores, etc.), we return to a single, easy-to-manage storage solution:  the on-disk store
in ~/.subversion/auth/
 * Portability:  ~/.subversion/auth/ is portable across computers, allowing users to transfer
what could be hundreds of different sets of stored repository credentials to other machines
with ease.  So long as they employed the same master passphrase on those other machines, or
did a one-time passphrase change, they would be able to make use of previously cached credentials.

== Concerns ==

 * Implementation of built-in encryption mechanisms tied to a "master passphrase" secret key
might possibly complicate Subversion's distribution per the export control restrictions placed
on such technologies. We need to understand and carefully consider the scope of that complication.
 * Is the Subversion codebase -- and the authn subsystem specifically -- capable of handling
this sort of approach?  (Research continues.)

Mime
View raw message