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

Re: passwords in subversion

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-12-12 23:39:29 CET

Secret management is a complex, open-ended problem on both the client
and the server side of any network application. I don't think
Subversion should entangle itself very far in this realm without the
help of (optional) supporting libraries.

svnserve's cram-md5 support is a deliberately oversimplified stopgap
solution to the authentication problem. I could have made the shared
secret a hash of the password rather than the password itself, but
that would have meant requiring a tool to maintain the server password
file. While I'm quite aware that staring at a list of plaintext
passwords is at best uncomfortable to the administrator, I really
didn't want Subversion to have more than a tiny amount of its own code
devoted to a security protocol implementation. If svnserve were to
store hashed secrets, we'd still have the complaints that users have
no in-band way to change their passwords, that svnserve doesn't
integrate with some existing password database, etc..

Here's what I suggest for security-conscious sites which want to use
svnserve password authentication for whatever reason: don't let users
select the passwords. Assign them randomly and provide users with a
way of fetching them. (This could be done via https or various
lower-tech solutions.) The users will likely be using svn's
password-caching and won't need to remember the password. If the
admin uses a screen which can be seen by passers-by, write a small
script to manipulate the password database so that passwords don't
show up on the screen.

Obviously, in an ideal world Subversion admins shouldn't have to write
scripts to do out-of-band password management. Here are long-term
solutions I would find reasonable:

  * Integrate Cyrus SASL. I have a number of issues with this
    library, but we should probably just ignore all of them and
    integrate it anyway. Note, however, that Cyrus SASL stores
    cleartext passwords for digest-md5 and cram-md5 auth; it just
    stores them in a database.

  * Allow plain-text password auth if the connection is using SSL.
    This allows integration with a variety of back-end password
    databases, and Cyrus SASL will take care of the details (PAM,
    Kerberos, maaaybe NTLM on Windows but I'm not sure). Even if the
    admin uses local Subversion password database, it can contain
    hashed passwords if PLAIN authentication is used.

  * On the client side (this is not specific to ra_svn), rather than
    writing our own svn-agent as has been proposed, we should keep our
    eyes open for libraries which do secret management. GNOME has one
    at this point; maybe it's good enough for us.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 12 23:41:08 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.