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

Re: [PROPOSAL] A new (simple) authentication mechanism for svnserve

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2005-07-30 11:42:04 CEST

On Sat, Jul 23, 2005 at 04:05:21PM +0200, David Anderson wrote:
> 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.

This has been suggested before:


I pointed out that similar results can be obtained via a process change,
rather than a code change:



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 30 11:43:03 2005

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.