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 Mon, 02 Jul 2012 18:45:16 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?action=diff&rev1=30&rev2=31

Comment:
Add a section with a suggestion about using ssh-agent received from a drive-by reader

  = 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.
@@ -87, +88 @@

  }}}
  Note that the above algorithm is similar to how we actually store target passwords (substitute
the password for `STUFF` with appropriate prefixing and padding).
  
+ === SSH-Agent as a master password cache mechanism ===
+ Ivan Voras <ivoras{__AT__}gmail.com> provided the following suggestion (via private
email to CMichaelPilato; posted here with permission):
+ 
+ {{{
+ From: Ivan Voras <ivoras{__AT__}gmail.com>
+ Date: Mon, 18 Jun 2012 16:06:54 +0200
+ Message-ID: <CAF-QHFVKV366BwDN7kK1YeiQY95Y83jB1xtP6Zx9U9=U+pTGrw@mail.gmail.com>
+ Subject: Subversion Master Passphrase Support
+ To: cmpilato@red-bean.com
+ 
+ Hello,
+ 
+ I have been searching for something in the Subversion wiki and
+ accidentally came across the
+ http://wiki.apache.org/subversion/MasterPassphrase page, which is
+ signed by you.
+ 
+ I think this is a very valuable feature but would like to suggest a
+ different approach: rather than reinventing the wheel and making your
+ own master-password maintenance mechanism, it would be better, more
+ convenient and even perhaps more reliable to use ssh-agent for this.
+ 
+ See:
+  * http://en.wikipedia.org/wiki/Ssh-agent
+  * http://www.freebsd.org/cgi/man.cgi?ssh-agent
+  * http://ptspts.blogspot.com/2010/06/how-to-use-ssh-agent-programmatically.html
+  * ... and others.
+ 
+ As the ssh-agent does PKI crypto by itself, I think the workflow would be:
+ 
+ 0) User creates an ssh keypair protected by a master password. This
+ keypair is also used for normal ssh communication.
+ 1) When master password is enabled in svn (by a user command, etc.),
+ svn needs to create a 256-bit random internal master password, make
+ ssh-agent encrypt it, then store the encrypted internal master
+ password wherever
+ 2) To decrypt data, svn needs to ask ssh-agent to decrypt the internal
+ master password, then use it in whatever way necessary
+ 
+ The benefits are that most professional users already have ssh keys
+ handled by ssh-agent, that ssh-agent already solves the problem of
+ protecting sensitive data and asking for the master password, and that
+ by using a random internal master password you guarantee better
+ security against brute-forcing the protected data.
+ 
+ The workflow I described should work - in theory - but I haven't tried
+ to implement it!
+ }}}
  == 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.

Mime
View raw message