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 Thu, 05 Jan 2012 14:37:14 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=6&rev2=7

Comment:
Note the insecurity of the GPG apent.

  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. 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 encrypted storage mechanisms.
+ 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. 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.
  
  === 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.
@@ -16, +16 @@

  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.
  
  === GPG Agent ===
- Subversion's 1.8-dev codebase currently offers an integration with GPG Agent, which is yet
another third-party cryptographic service provider.
+ 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?

Mime
View raw message