Re: user authentication
From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-11-15 18:54:14 CET
Ray Johnson wrote:
> where each path in the history of a file is checked for security. Since we did a massive import of our repository it means the command apparently has to check the security for several thousand paths. This causes "svn log" to take longer than 5 minutes for a file of minimal history. As I understand it this is more related to path authz - but is related to the whole Apache security package. (Not sure how much of the cost is authentication on all those paths or just the cost of looking at so many paths.)
>2) The NT Auth stuff requires a user name of "domain\username". Ideally, we would prefer folks to just put in "username" as the domain is the same for everyone.
> Aside from the "ease of use" issue, it is also a problem for us because it makes "svn ls --verbose" useless to us. One would use "svn ls --verbose" to see who modified a file in a directory - but svn will truncate the username to 8 characters - all we ever see is the domain name. If we could do our own auth and use username only we could work around "svn ls --verbose"'s design flaws.
>2a) If I was implementing my own authentication I would also make the username case insensitive. It is very common for me to have to explain to new Subversion users that while everywhere else their username is case insensitive - in Subversion it is not.
>3a) The "domain\username" scheme is also a pain with the svn client. When the svn client needs to do auth (or re-auth because of a password change), it "guesses" your username as the username your logged into. However, it doesn't put the domain in - so it always guesses wrong. Getting rid of the domain would "fix" this issue. Alternatively, you could fix the client - but that somehow seems harder...
>A properly designed "hook" for authorization could allow us to fix these issues. It would also allow us to use our security model when using the "svn:" protocol - which would be nice.
>P.S. - While on the topic of security - I'll also mention that caching the users password in clear text is a serious issue on a Windows machine.
I'll be putting this in the FAQ soon. It does require Win2k or later and
> Windows security isn't that great to begin with but Subversion makes it much easier to get the users actual password. BTW, here is an exploit I've already seen: User asks "friend" for help with Subversion. Friend uses Subversion from users machine _without_ using "--no-auth-cache" on some command. Now user has access to friend's password. I kind of think --no-auth-cache should be default if your going to store password in clear text...
This is an archived mail posted to the Subversion Users mailing list.