Re: user authentication

Ray Johnson wrote:

>
>
>Sure - I'd be happy to explain in more detail. We are currently using the NTAuth stuff in Apache so that users can use the same authentication they use to log into their computer. We have the following issues with the current implementation:
>
>1) Since SVN 1.1.1 - the "svn log" command has become completely unusable for us. This is due to the "security fix"
>
It is a security fix, not a "security fix", because it prevents
potential leaksing of information to unauthorised recepients.

> 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.)
>
>
Are you aware that you can turn the sub-requests off? If you're not
using mod_authz_svn, that is.

>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.
>
This of course has nothing to do with Subversion, it's an Apache issue
(and IIRC also easily fixed -- at least I've seen posts to that effect).

> 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.
>
>
I wish you weren't so free with the "design flaws". It's a bug, yes,
which isn't the same as a design flaw. I know someone's been fixing it,
and it might actually be fixed in 1.1.2. Generally, coherent bug reports
tend to have much better effect than

>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.
>
>
Again and for the last time, authentication isn't Subversion's job if
you're using DAV, it's done by Apache. Of course, you can modify the SVN
client to canonicalize the username, after all that's why we have a
plugin architecture (for gathering authn information, that is, not for
_doing_ authentication).

>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...
>
>3) The Apache NT Auth stuff does not support NT Groups. While you can set up your own "groups" in Apache - we would much rather use the Active Directory groups we are already maintaining to use for path authorization. The entire point of using the NT Auth stuff is to reduce maintenance points and the current implementation doesn't quite go far enough.
>
>
You keep listing problems on the Apache side. None of these are strictly
Subversion problems. By the way, since you use Active Directory, have
you tried Apache's mod_auth_ldap?

>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.
>
>
Well, I concede that svnserve doesn't have authentication hooks. But
that's why we support Apache, which does.

>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.
>
    C:\> cipher /E /A "%APPDATA%\Subversion\auth"

I'll be putting this in the FAQ soon. It does require Win2k or later and
NTFS, but I can't imagine you'd use anything else.

> 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...
>
>
That would be the case regardless of whether the password was encrypted
or not. The only solution is to totally prevent password caching, for
which there is an option in the Subversion config file.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 15 18:54:35 2004