chrislott@spamcop.net wrote:
> This is a "me-too" message. I strongly, deeply request you give priority to the
> proposal for a new auth mechanism for svnserve. It would help us immensely if
> it had a mechanism so passwords don't have to be in the clear; perhaps they
> could be stored like Apache passwords (encrypted with htpasswd).
I can understand why you'd like some other storage mechanism here.
However, Greg's point on why we shouldn't keep on expanding what was a
temporary fix to the absence of a real SASL library is very good. His
point about overly complexifying the user's experience with utilities to
manage the hash-pass-db and such is also excellent. As a consequence to
this, once my summer of code assignment (authz support) is complete, I
plan on doing something about all this the right way.
The problem there is is that cram-md5 is nice because it doesn't
transmit any reusable auth token over the wire, making it generally
immune to replay attacks on authentication. The downside is storing the
password in cleartext on the server. Other authentication methods that
people often consider using have it the other way round: password is
hashed on the server, but the hash is transmitted as is over the
network, making replay attacks easy. There are of course some that take
the best of both worlds, but they often imply some heavy artillery
implemented on the server to get it to work.
Add to this the problem that the interim solution I was proposing means
introducing an authentication method that is some sort of hybrid between
cram-md5 and digest-md5, that doesn't actually exist in SASL world. That
will mean problems keeping it there once real SASL support is
integrated, not to mention the diplomatic rudeness of creating a new
auth mechanism in the SASL namespace "because we need it".
All this to get to this conclusion: if we want to properly upgrade the
user's sense of security whilst at the same time preserving real
over-the-wire security, we need both real SASL and SSL integrated to
svnserve. This will not be quick in the making. I'd like to tackle both,
but I doubt anything can get done for the next release.
In the meantime, I suggest teaching your users a somewhat different
password management policy when related to svnserve. Rather than putting
passwords given by users in the password file, have each repository
"admin" generate passwords (hint: `pwgen` does this well) and assign
them to users. Users can then use client-side auth caching to not have
to worry about remembering twenty obtuse passwords. This removes some of
the problems of users being able to read password files: all they gain
access to is to the corresponding repository (of course, if that is a
problem, then you do have a problem. But if these are employees, what
benefit have they to hack into each other's projects instead of asking
for access?)
Okay, so it's not nirvana, but until some SASL/SSL find their way into
svnserve, I fear that will be your only option. But bear with me,
barring major incidents, I'll soon be addressing the problem.
> I'm sure not an authentication or encryption expert, but I can try to work on
> this problem if someone can get me started. (No, I'm not a student, this is
> not a summer of code for me. :-/)
If you want to put up for the interim fix to cram-md5, and manage to
convince others that the fix is worth it until real SASL comes along
(but read back through the problems Greg gave - they are not by any
means minor), then be my guest. I'm willing to provide guidance to help
you get this into the code.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 28 18:48:46 2005