[Cvs-dev] Re: cvs-passwd patch

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

P J P <address@hidden> writes:

> On Tue, 17 Oct 2006, Mark D. Baushke wrote:
> > No worries. However, I don't see a good reason that a non-administrator
> > would ever need to change any password other than their own, so if they
> > were able to authenticate for start_server, then using that username
> > should be sufficient to prove that they are who they say they are.
> 
>    No, it's not that simple! In my experience, I've seen many people,
> who just don't do 'cvs logout', they forget it(I don't know how/why).
> In that case, it becomes childs play for anyone to change someone
> elses password.

Okay, I understand your argument. Of course, if the .cvspass file is
visible to the user, then it is trivial to descramble the password that
is in the file. There is absolutely no security there for the existing
kinds of passwords.

http://archive.cert.uni-stuttgart.de/archive/bugtraq/2004/07/msg00310.html

Greg has a good point...
http://archive.cert.uni-stuttgart.de/archive/bugtraq/2004/07/msg00321.html

> So, I think, that authentication is required.

If so, you could do it locally without calling the server by just doing
a descramble of the .cvspass entry for the :pserver: the major problem
is that if the method is not :pserver:, then you might not be able to
determine which :pserver: entry matches the CVSROOT being used.

I can think of a few ways to deal with it, but it is very late and they
may not be useful...

 1) ask the server if you should authenticate or not, (it could 
    look at the CVSROOT/config file)

 2) look at the timestamp on the .cvspass file. If it is not fairly
    recent, then you know that they have not re-typed any of their
    passwords recently.

> > In addition, not calling connect_to_pserver() means that any other
> > authenication method could be used if available. So, if they are able to
> > run cvs on the local server in :local: mode, the fact that they could
> > login as that user should be sufficient to indicate that they are able
> > to change their :pserver: password. Likewise with :ext: or any of the
> > other methods.
> 
>    Yes!, you'r right!! Instead of calling connect_to_pserver(), I
> should call something, which will work for any method, and not just
> ':pserver:'.

Yes.

> > I believe that a length check should only be done on the client.
> >
> > Hmmm... It should probably also only be a warning. If CVSNT ever changes
> > the maximum, then we should not inhibit it. I have not looked closely to
> > see if anything else imposes a maximum on the allowed passwords. I see
> > that you have imposed a minimum which is a fine idea.
> 
>    so, I should just throw some warning, and let continue the
> operation, right?

Yeah, that would probably be sufficient for now.

> >>    Should I just warn about it or abandon any such attempt??
> >
> > I would abandon the attempt. The current protocol does not really allow
> > another round trip to the user to ask if they really want to proceed or
> > not, so best not. I suppose a forcing flag on the command line might be
> > okay if a user really did want to remove themselves, but I would not put
> > the effort into that extension right now.
> 
>    Okay!
> 
> 
> > You have the option of asking the other cvs-dev folks for a vote.
> > However, I would probably not continue with the integration in that
> > case.
> 
>    It's okay! I'll do the changes!!

Good luck.

        -- Mark

Here is a trivial perl script to descramble the passwords passed to it
on STDIN.

#               --------------- cut here ---------------
: # use perl
eval 'exec perl -S $0 ${1+"$@"}'
    if 0;

my @shift = (
    0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
   16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
  114,120, 53, 79, 96,109, 72,108, 70, 64, 76, 67,116, 74, 68, 87,
  111, 52, 75,119, 49, 34, 82, 81, 95, 65,112, 86,118,110,122,105,
   41, 57, 83, 43, 46,102, 40, 89, 38,103, 45, 50, 42,123, 91, 35,
  125, 55, 54, 66,124,126, 59, 47, 92, 71,115, 78, 88,107,106, 56,
   36,121,117,104,101,100, 69, 73, 99, 63, 94, 93, 39, 37, 61, 48,
   58,113, 32, 90, 44, 98, 60, 51, 33, 97, 62, 77, 84, 80, 85,223,
  225,216,187,166,229,189,222,188,141,249,148,200,184,136,248,190,
  199,170,181,204,138,232,218,183,255,234,220,247,213,203,226,193,
  174,172,228,252,217,201,131,230,197,211,145,238,161,179,160,212,
  207,221,254,173,202,146,224,151,140,196,205,130,135,133,143,246,
  192,159,244,239,185,168,215,144,139,165,180,157,147,186,214,176,
  227,231,219,169,175,156,206,198,129,164,150,210,154,177,134,127,
  182,128,158,208,162,132,167,209,149,241,153,251,237,236,171,195,
  243,233,253,240,194,250,191,155,142,137,245,235,163,242,178,152);

while(my $line = <>) {
    chomp;
    my $pw = '';
    if ($line =~ /^A/) {
        for ($i = 1; $i < length($line); $i++) {
            $pw .= chr($shift[ord(substr($line, $i, 1))]);
        }
        printf("pw is '%s'\n", $pw);
    } else {
        printf("invalid scramble: %s\n", $line);
    }
}
__END__

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFNLklCg7APGsDnFERAjPRAJ9l6lZwCxUNUMvBGK34EVxDKptQhQCgmfHP
MhvL5sTf23TUFo/Z8WNtvYE=
=bRY0
-----END PGP SIGNATURE-----