[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: using (or coding support for) encrypted passwords

From: Peter Samuelson <peter_at_p12n.org>
Date: 2006-10-21 00:56:52 CEST

[Alexis Huxley]
> Is there any way to use encrypted passwords in <repo>/conf/passwd
> instead of plaintext?

http://svn.haxx.se/dev/archive-2006-10/0508.shtml

This is basically just like ~/.cvspass, i.e., not actual encryption.
But the client-side hash verification scheme you propose is pretty much
equivalent, since in both cases anyone who gains access to
~/.subversion can authenticate with the server. The only advantage to
a one-way hash is the case of "perhaps I used the same password for
amazon.com".

The alternative is to interface to a system-level password management
daemon which, presumably, needs to be "unlocked" with a password, to
decrypt its stored data, when the user starts his session. The
advantage is that Subversion doesn't have to reinvent secure password
storage - it's a complex job much better left to someone else. No need
for Subversion to know about Blowfish, USB flash drives, or smart card
readers. Subversion already supports such facilities on Windows and
Mac OS X; there is talk of supporting more such daemons, such as GNOME
Keyring, kwallet, and quintuple-agent.

> Secondly, is there any way for the server (apache+mod_dav_svn and
> svnserve) to 'force' the client not to cache svn:// and http:// repo
> access passwords in plaintext?

No, there is in general no way for the server to control client
configuration. What you want is in ~/.subversion/config, in the [auth]
section, "store-passwords = no".

Pushing client configuration from the server is one of those things a
lot of people request, but nobody has produced a design. It also has
security implications - you don't want the server to control very much
of the client configuration, as there is no reason for a random client
to trust a random server (svn is often used in an "anonymous" situation
where the client user does not, in fact, have any particular way of
knowing that the server administrator is trustworthy).

Received on Sat Oct 21 00:57:10 2006

This is an archived mail posted to the Subversion Dev mailing list.