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