On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
> The client should be able to store the credentials if you have it set up to do so. On windows/mac it is encrypted with OS included libraries. For Linux you need to set up gnome keyring or kde-wallet.
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache
Warning up front: this is a long analysis, and slightly ranting. I'll
shorten it up to say "this is completely unreliable and misleading
documentation".
Let's quote it, shall we?
> •For other Unix-like operating systems, no standard “keychain” services exist.
This is the fundamental problem, coupled with the default enabled
storage of passwords and no way to prevent it on the server.
> However, the Subversion client knows how to store password securely using the “GNOME Keyring” and “KDE Wallet” services.
Both of these tools require bulky sets of dependencies not mentioned
or documented except, these days, in the on-line book. They're not
installed by default, and using them from a non X session or a remote
X terminal or Putty is damned akward. There are published widgets to
aid this, such as the "gkeyring" utility, but they're not standardized
yet in any UNIX or Linux distribution that I can find. So this claim
is classic handwaving.
> Also, before storing unencrypted passwords in the ~/.subversion/auth/ caching area, the Subversion client will ask the user for permission to do so.
This feature was only, finally, added in Subversion 1.6. Quite a few
operating systems don't provide this recent a version: RHEL and
CentOS, for example, are still stuck at Subversion 1.4. And it can't
be enforced on the server, it's entirely client side optional
behavior.
> Note that the auth/ caching area is still permission-protected so that only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical access to the storage media of the home directory, or backups thereof.
And whowever wrote this has no idea what they're talking about. I'm
going to be crude for a moment: this is complete horseshit.
First, many backup systems are often enabled to allow network based
recovery. After all, who would be stupid enough to put clear text
passwords on their backup tapes?
Second, many working environments in the UNIX world rely on NFS based
home directoies, to share working environments and configurations
across a variety of machines. In such environments, *any* host that
can be leveraged to local root access can "su" or "suco" to become the
target user, and access their entire home directory.
Think I'm kidding? Walk into any university environment: plug in a
live Linux CD. Run an "nmap" scan for hosts running NFS. Run
"showmount" to detect what NFS shares are published to everyone. Go
ahead and mount the shares. Look in them for home directoriies. Look
in them, using your local root privileges, for Subversion passphrases.
(Look for CVS passphrases and un-passphrase-protected SSH keys while
you're at it.)
This requires no internal knowledge of the remote system, and can also
be done by any rootkitted system on the network. If you happen to
already know the environment somewhat, just lok into any local system
and take some notes.
So, "local physical access', my eye. The equivalent to this behavior
is taping your front door key under your front door mat. After all, if
they're on you porch, you trust them, right? They must be your
neighbor if they're on your street! This is how many business and
educational environments treat their networks: once you're inside the
perimeter, you're assumed to be trusted and have tremendous access,
because locking things down further requires time and money and
inconvencience to the people trying to do their work. So, assuming
that "local physical access" is required is an extremely ill-founded
assumption.
Now, allow me to quote the next part:
> Of course, for the truly paranoid, none of these mechanisms meets the test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials caching system altogether.
It's not paranoia when they *are* out to get you. And these days, with
cracking kiddies wandering the world and people working in large
shared networks, they are out to get you just as a hobby. And the
"ways of disabling its credentials caching sysem" are all local client
configuraton based. They are entirely reliant on owning the local
installation, and *none* of them are on by default. Very few
Subversion administrators have such direct control of the client base:
I've run it for small and large companies and home setups, and *never*
had that kind of control.
Look, Subversion inherited its practice of storing password in
cleartext from its ancestor, CVS. It's been an uphill battle ever
since to wallpaper over the practice: there are enough layers of
wallpaper, finally, that it's almost thick enough to be a wall. It's
fixed for TortoieSVN, and svn+ssh using SSH keys can work well. But
*every single client* I've had in the last... four years has wanted to
use their Windows passwords, and balked when I showed them this
problem. Some gave up on password authentication, and simply used
blank svnserve passwords to enforce the setting of usernames and
logging of changes. Others went with SSH keys. Some refused to believe
me, because "it uses HTTPS, they can't be stored in plaintext". (That
took some extra work to disprove: it was a director of security, who
couldn't imagine that any commercially supported software could be
that stupid.)
Look, I'm glad that Subversion finally started asking before storing
passwords in version 1.6. That was a big step forward over its former
practice of storing it unannounced, but guess what? Version 1.5 and
1.4 are still in use commercially. (Look in RHEL 5 and CentOS 5:
they're still at Subversion 1.4.) I have had people in the last year,
as part of new subversion client setups, go ahead and store their
passwords locally thinking "of course it's stored encrypted, it uses
HTTPS!!!". And I've shown them their own Windows login passwords and
therefore email passwords this way, and opened up their email in front
of them to show the problem.
All that said, I'll call this my "annual rant on the subject", and
simply post links to it when it comes up again. It does need
occasional explanation, for newer users unfamiliar with the security
implications of this local password storage problem.
Received on 2010-10-09 15:40:28 CEST