On Mon, 13 Jan 2003, Justin Erenkrantz wrote:
> --On Monday, January 13, 2003 13:39:52 -0800 email@example.com wrote:
> > If I am using ssh tunneling with an actual account, I will not ever have a
> > .cvspass file. I am using SVN over SSL, so I know that my passwords are
> > safe over the network, but without this change, they aren't safe on my own
> > hard-disk. Show me somebody who actually uses :pserver: with their _real_
> > password, and I will show you a user with a security hole.
> I know PHP only allows write access with CVS's pserver, so it's not unheard
> of with CVS. It's a security hole, but so what? Their attitude is that
> "it's versioned!" =)
Ahhhh, but PHP went into with their eyes open. The page that allows you
to request a CVS account used to make it clear that it was using pserver,
and what that meant. (at least I thought it did). That seems to be gone
now. In the current svn code, there is nothing that ever says, BTW, we
are storing your password in the wc for you.
> If you want 'secure' local storage right now, you should be using ra_svn
> with an appropriate SSH agent forwarding. No username/password combination
> should be required then.
But I don't want a secure local store for my password. I don't want my
password stored on the box, at least not by default. For some repos,
sure, put my password in there, it is a public account on a machine that
doesn't use SSL. But for my box, which does use SSL, don't even think of
putting my password in plain text on the machine.
> > The second difference is that CVS doesn't put the username/password combo
> > in the checked out repository itself, SVN does. This means that you can't
> > share your checked out repo with anybody, ever.
> Which, as I suggested, following CVS with a file in ~/.subversion might be
> a fair compromise solution.
> But, I believe that if we disable auth caching by default, we've just made
> the system that much harder to use for people familiar with CVS. We
> *should* cache the passwords by default.
> Claiming that it makes it more 'secure' hides the fact it makes it far less
> 'usable.' No one wants to type their password over and over again. What
> you're suggesting is that people type their password everytime. They'll
> get around that by having a little sticky-note on their monitor, or using
> insecure-but-easy-to-remember passwords, or, probably, just turning on auth
> caching. -- justin
convenience and security are always at odds. That is fine, it is the way
of the world. What we are asking for, is defaults that encourage
security. If people make a conscious decision to be insecure, cool. But
that needs to be a decision. The current state is insecure by default,
and a conscious decision for security. That is wrong, and it is why most
Unix devlopers hate Microsoft, it is their default position.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jan 14 01:33:52 2003