[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnserve password store in clear text

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-06-02 21:35:31 CEST

On Wed, 2004-06-02 at 15:21, Jon Foster wrote:
> If the server was storing a hash of the password and the server name
> (aka authentication domain), would that mean if the client refers to
> the server differently (e.g. using localhost because they're
> tunnelling over SSH) then the user needs to reset their password?

It would. That would seem to be a big problem. I can think of
variations, but they all have the same or similar problems (e.g. we
could hash the password with the repository UUID, but then the password
db couldn't be shared between repositories).

The authentication domain does have a server-specified component.
Administrators are not strongly urged to set it. We could hash the
password with just the server-specified component, change the comments
so that the administrator is strongly urged to set it, and note that
passwords will be invalidated if it changes.

> Also, it stops administrators from seeing the password accidentally.

My assumption has been that it's easy to edit the password db in an
automated fashion, but I guess that's not very admin-friendly since we
don't provide tools to do so.

> E.g. I run a small SVN server at my company, but I'm not a proper
> system administrator. Users want to use the same password for the
> SVN server as for the network.

I'll observe that with credentials caching, it's not terribly hard to
use a different password for each, since you don't have to remember it
each time you use svn.

(Also, pet peeve: "for the network?" Since when does "the network" have
a password?)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 21:36:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.