1. ABSTRACT
This document proposes a new authentication method for svnserve, to
address perceived problems with the current method. It has been briefly
discussed on IRC, and is now here for your consideration.
2. PURPOSE
Svnserve currently has a single authentication mechanism (I do not
consider the use of svn+ssh:// to be one for this proposal, as it
entails another set of problems), cram-md5 challenge-response.
A quick reminder of how this works. cram-md5 requires both client and
server to have access to the cleartext password. To authenticate the
client, the server sends a random challenge over the wire, to which the
client replies to with a hash of information that proves he knows both
the challenge (to avoid replay attacks) and the cleartext password. The
server verifies this, the password is never transmitted as cleartext
over the network, and there is much rejoicing. This method is secure
against sniffing of transmissions.
It does however have one problem, not technical, but social. Cram-md5
requires that the server have access to the cleartext password. The
upshot of it is that the user's passwords are stored as cleartext in the
password file.
This is not a security problem, as the file is not world-readable (or at
least it shouldn't be). It is a social problem because users are
sometimes irrationally uncomfortable about having their passwords stored
as cleartext, and administrators are often uncomfortable with being able
to read cleartext passwords. There is also a minor security issue if
users provide a password they frequently use, or reuse their given
password in other places; a malicious administrator could gain
unauthorized access to other systems.
3. THE (SIMPLE) SOLUTION
There is a way to correct all the aforementionned issues without
resorting to implementing other, more complex authentication methods
(though this would certainly be nice in the more distant future). The
solution is simply to redefine what "cleartext" means in this context.
Define "the cleartext password" to be "the hash of the password the user
authenticates with". Store that hash (the new cleartext) on the server.
Prompt the user for his password, then hash it before inputing it into
the cram-md5 black box. The cram-md5 algorithm itself is not altered,
and will continue to perform as usual, ensuring that no authentication
information is sent in an interceptable form.
The issues are resolved: the administrator no longer has access to
meaningful cleartext passwords (he can still use the hashes and a
modified svn client to authenticate in-lieu of the user, but as the
administrator he can do that anyway), no longer has potential access to
other systems. Users are satisfied that they are not using passwords
that are stored in cleartext, and that they need not give away a
cleartext password to the administrator.
I once again stress that the point here is not to provide any added
security. It aims only at resolving the issues people have with storing
cleartext passwords, and accomplishes nothing more.
4. THE PLAN
Implementation would be perfectly simple, if it weren't for the issue of
compatibility: if we just insert hashing functions at strategic points
in the current code, old cleartext user files will cease functionning.
Two options:
A. It is considered a reasonable collateral to have people upgrading to
1.3 (assuming the change would go in there) run a crunching script that
converts their pass-db to use hashes, in which case the patch is
extremely simple and changes next to nothing to the code of both
svnserve and the svn RA lib.
B. Breaking pass-db compatibility is not acceptable in a minor release,
in which case both cleartext and hash-cleartext methods need to be
supported. The solution to this is to add an extra authentication
method to the svn RA, something like CRAM-MD5-HASH, which implements the
extra hashing level. Either the hashes stored in the password file need
to be recognizably hashes, or a configuration option defining which
style of password file is being used must be provided, so that svnserve
knows what authentication mechanisms to offer the client.
There is also the question of the adding of passwords to the passwd
file. svnadmin will need a command that either handles adding/removing
users from the passwd file, or at least a command to produce a password
hash. It would be nice to make the used hash format compatible with
htpasswd2 or another widely used system, so that users can generate
their hash without svnadmin or giving away their password to a third party.
5. CONCLUSION
Two main issues with this proposal arose:
A. Does adding a level of hashing outside the cram-md5 blackbox alter in
any way the security of the cram-md5 exchange? We could not discern any
security issue with changing what cram-md5 uses as plaintext, but if
there is such an issue, the proposal is obviously binned.
B. Does anyone actually care enough for this change to be worthwhile? Is
it best to forget about this and focus on a later and longer-winded
implementation of extra, totally different authentication methods? I
suspect this is the answer to "if it's so cool, why isn't it already
done?": insufficient interest from developers.
On that second point: if nothing happens with this by the time I finish
my SoC assignment AND it is considered an interesting enough proposal to
implement while waiting for other, "better" authentication methods, I'm
willing to give it a twirl.
There ya go. Have fun shooting it down.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 23 16:06:23 2005