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 "EncryptedPasswordStorage" by CMichaelPilato
Date Mon, 16 Jan 2012 20:50:15 GMT
Dear Wiki user,

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

The "EncryptedPasswordStorage" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/EncryptedPasswordStorage?action=diff&rev1=12&rev2=13

Comment:
Reorganize some thoughts and drop a poorly thought out idea.

  }}}
  For many users, this solution is secure enough. 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.  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.
+ 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 credentials 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.
+ 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
  
+ {{{#!wiki note
+ Is there any system extant which is secure when another user might have root access on the
machine?  Surely with keystroke loggers and other sorts of software which a root user could
install, true security on any such a system is flatly unavailable.  So, what is the real impact
of the GPG Agent "SECURITY CONSIDERATIONS" listed above?  How might gpg-agent's default timeout
mitigate that impact?
+ }}}
  == 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?
  
- == Suggestions From Other Software ==
- === Firefox ===
+ == Improvements We Could Explore ==
+ === Built-in Encryption with a Master Passphrase ===
  Like all popular web browsers, 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 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)
  
- In theory, Subversion could do something similar, but the short-lived nature of the command-line
client means that a user would typically need to provide the master password as often as they
would their repository credentials (which renders credential caching rather pointless).  This
approach would only be useful if there was a way to securely persist the master password across
command-line client invocations.
+ In theory, Subversion could do something similar, but the short-lived nature of the command-line
client means that a user would typically need to provide the master password (or passphrase)
as often as they would their repository credentials, rendering the credential cache rather
pointless.  This approach would only be useful if there was a way to securely persist the
master passphrase across command-line client invocations for at least some period of time.
  
+ One way to do so would be to use a daemon-based persistence layer (for example, the GPG
Agent) to hold the user-provided master passphrase in memory.
+ 
- {{{#!wiki note
- Is there any system extant which is secure when another user might have root access on the
machine?  Surely with keystroke loggers and other sorts of software which a root user could
install, true security on any such a system is flatly unavailable.  So, what is the real impact
of the GPG Agent "SECURITY CONSIDERATIONS" listed above?  How might gpg-agent's default timeout
mitigate that impact?  And finally, could the gpg-agent be used for the storage of not Subversion
passwords, but of merely the "master password" which is used to encrypt/decrypt disk-cached
credentials?
- }}}
- {{{#!wiki note
- Even with the existing keyring integrations, we still make use of the runtime configuration
area's auth/ subdirectory.  Most of the credential information for every realm is stored on
disk, with either a "password" record (and plaintext password) or a "passtype" record that
tells Subversion where to look for the password ("gnome-keyring", "gpg-agent", etc.)  Would
we better served (in simplicity and consistency) by using the externals stores for nothing
but a master password and always store the encrypted form on disk?
- }}}
  {{{#!wiki warning
  Implementation of built-in encryption mechanisms tied to a "master password" 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.
  }}}

Mime
View raw message