[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Cvs-dev] Re: cvs-passwd patch
From: |
Mark D. Baushke |
Subject: |
[Cvs-dev] Re: cvs-passwd patch |
Date: |
Sun, 22 Oct 2006 21:55:02 -0700 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Call for cvs-dev opinions:
Poll A: Is it required/desirable/undesirable that an administrator be
able to use non-:pserver: connections to the cvs server in order
to manage passwords of all the :pserver: user passwords?
Poll B: Is it required/desirable/undesriable that a CVS user who has
both a :pserver: as well as a non-:pserver: connection method be
able to manage their password using the non-:pserver: connection
method?
Poll C: Is it required/desirable/undesirable that a user who has
successfully done a server_start() wherein their password has
been sent to the server once already (by reading the .cvspass
file) be prompted for their old password when setting a new
password?
Poll D: If #C is required, then if the client is connecting over a
non-:pserver: method, how should the user's old password be
validated?
I have more comments inline below.
P J P <address@hidden> writes:
> On Fri, 20 Oct 2006, Mark D. Baushke wrote:
> > First, the 'cvs passwd' command is not a replacement for the way that
> > the operating system sets the password. It should never even consider
> > trying to modify credentials that are not totally under CVS control.
>
> Sure! I understand it!!
>
>
> > The case where user Alice does a 'cvs login' and leaves the shell window
> > open is a problem in more than one way. Such a user could have someone
> > to a 'cvs commit' on their behalf with a trojan or other evil changes.
> > That such a user might have to contact the administrator to have the
> > password reset seems like a good learning experience and might alert the
> > adminstrator that the user may have committed code that should be audited.
> > In addition, there is nothing to say that the evil user Bill could just
> > copy the .cvspass file for later mischief and do a trivial descramble of
> > the file and modify the password at a later time.
>
> Oh, of course, such evil user can do everything, that Alice can do. And
> thus, considering the stakes involved, and that, the password is of utmost
> importance to Alice, it makes sense to double check that, the user who is
> trying to change Alices pasword, is indeed Alice herself.
Hmmm... I thought I just 'proved' that if Alice did a login and walked
away all bets are off. The normal scrambled passwords are completely
reversable.
> > In any case, I fully expect that the administrator at least should be
> > able to use a secure protocol to issue the 'cvs passwd' command to do
> > user administration.
>
> Yes sure! but, does that mean, by using a *different method* altogether?
Yes, to me, that is what it means.
CVS adminstrators can put all users at risk by exercising an indiscrete
connection path. A normal CVS user may only put themselves at risk.
When I administered a KDC, I might let my user-level password be used in
potentially exposed situations such as dialup or using a potentially
compromised client, but the adminstrator password was only used over
encrypted hardwire connections that were not vulnerable to eavesdropping
and were running on hardware know to not be compromised.
> For that, I think, the :pserver: protocol it self should support *secure*
> communication, isn't it?
:pserver: is the least secure protocol that is supported by CVS. To even
hint that :pserver: is secure is to lie to oneself and anyone else that
is aware of the hint.
> > Choosing to disallow normal users from making password changes via other
> > protocols would seem to make their lives more complicated.
>
> I don't think so! in fact, I find it unreasonable. It's like saying, "I
> want to change my Yahoo-mail password using Gmail service" or vise versa.
More like, I want to go to the bank to change my checking account pin
number in front of a teller instead of doing it outside via a speaker
phone outside where lots of folks can hear both sides of the
conversation.
> > Do any of the other readers of this thread have opinions on this matter?
>
> hmmn, that might help!
I agree. More iinput from the other CVS developers (and our friend Tony
Hoyle) is desirable.
-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)
iD8DBQFFPEsmCg7APGsDnFERAowSAKDFcGeTV8NxojzzfcI0ux55BCOe3ACgjo7E
9al8i0fbtOAnnP+5TFxpnCs=
=R8Oa
-----END PGP SIGNATURE-----
- [Cvs-dev] Re: cvs-passwd patch, (continued)
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/13
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/13
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/16
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/16
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/17
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/17
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/17
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/20
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/20
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/20
- Message not available
- Message not available
- [Cvs-dev] Re: cvs-passwd patch,
Mark D. Baushke <=
[Cvs-dev] Re: cvs-passwd patch, Mark D. Baushke, 2006/10/26