On Fri, Nov 12, 2004 at 07:02:55PM -0600, Ben Collins-Sussman wrote:
> Guys, please stop redefining the problem. I never claimed I was
> providing security, or that doing a rot13 operation on the password was
> secure. I told you exactly what problem my proposal solves: users
> accidentally getting glances of passwords. This is the complaint I
> hear over and over and again.
I don't hear it that often and when I do the explanation of why there's
nothing you can really do about it satisfies them.
> Again, this assuming that the goal is "security". It's not. Of course
> the root user can go and peer into a chmod 700 ~/.subversion/auth
> directory and see the password. He just doesn't want to see it by
> accident, when tarring up somebody's homedir for backup, or whatever.
> People complain about this to me all the time, in email, IRC, and IM.
> Maybe I'm living in an alternate reality. :-)
>
> Not true. I see many more complaints about the client-side cleartext
> passwords than the server-side ones. Heck, there's even a FAQ for it!
> (http://subversion.tigris.org/project_faq.html#plaintext-passwords)
Of course that's the goal. If the goal wasn't security they wouldn't
care about glances. Unless there's some other reason why people care
about keeping passwords secret that I'm unaware of.
However, I fail to see why an admin is going to accidentally glance at a
file like this. The only time I've ever hear the glancing argument is
in relation to the server side. The logic there is that the admin has
to edit the file to maintain it. But why would an admin be poking
around in user files like this? You'd have to be looking for this file.
And tarring up a homedir doesn't display the files. So I consider this
argument invalid on the client side.
Even more to the point. The FAQ you point to encourages anyone who
cares about this to send a patch to change it. I've never seen such a
patch. Which leads me to believe that nobody cares about this after
they read that FAQ.
The reason we have the FAQ is becuase it save us from writing the same
answer over again (that password caching can't be secured). Not because
there is a valid argument for obfuscating those passwords.
> You guys are totally right about rot13 passwords being no more secure
> than plaintext passwords, there's no argument there. Until we get
> something like an 'svn-agent' daemon written, there will never be a
> "secure" caching solution. And many svn users already recognize this.
> (For example, a number of our customers simply disable svn password
> caching altogether.)
Disabling the caching is the right thing to do if you care about this.
> But in the meantime, there's a still small tangential problem that can
> be solved, one that CVS provides, and users have come to expect. Let's
> not mix the two problems:
>
> 1. solve the 'glancing' problem with a trivial scramble,
See this is where we disagree. I don't believe there is a glancing
problem on the client side. I've yet to hear anyone seriously complain
about it with that argument. I think you're mixing up the arguments on
the client side and server side.
> 2. file an issue to create some kind of svn-agent daemon, for real
> security.
>
> I'd much rather see effort put into #2, rather than new win32-specific
> crypt calls. I agree with Ben -- in the meantime, put Branko's
> recommendation into a FAQ or something.
Totally agree with this.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 15 21:45:54 2004