On Sat, 2005-07-23 at 16:05 +0200, David Anderson wrote:
> 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.
Incidentally, I recommend that people using cram-md5 with svnserve
assign passwords to the users (rather than have the users pick
passwords), and use credentials-caching on the clients to ease the
ensuing pain. Then there isn't so much of an issue with the
administrator being able to easily see the user passwords.
Certainly, there are environments where this isn't feasible, though.
> Define "the cleartext password" to be "the hash of the password the user
> authenticates with". Store that hash (the new cleartext) on the server.
So, Subversion should not be directly concerning itself with wire
protocol security. I picked the current implementation as a stopgap
because it could be done in very little code and (this is the key point)
very little user-visible mechanism.
Your proposal would require adding a new command-line tool to, at the
very least, hash passwords. I'm not at all happy with adding that much
user-visible complexity to the stopgap solution. We should integrate a
SASL library and let it solve the authentication problems for us rather
than expand our own stopgap solution.
> 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
We do not own the namespace of SASL mechanisms, and should not create
new ones willy-nilly.
---------------------------------------------------------------------
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:21:12 2005