On Tuesday 20 May 2008 6:28:58 pm David Glasser wrote:
> Subversion 1.5 supports SASL for svnserve authentication.
>
> --dave
>
Yes, but doesn't that require an external authentication manager? I
would like to provide a method for internal authentication using
non-plain-text stored passwords.
> On Tue, May 20, 2008 at 6:23 PM, Jeff Robins <jeffrobinssae_at_gmail.com>
wrote:
> > Hello,
> >
> > I have been following the mailing-lists sporadically and see
> > that work has begun on adding the ability to encrypt stored
> > passwords/credentials on *NIX machines, where they were being
> > stored as plain-text.
> >
> > I would like to bring up the sometimes touchy subject of
> > storing the passwords in the "passwd" file on the server in an
> > encrypted/hashed format.
> >
> > I would like to start out with stating that I understand the
> > following arguments:
> >
> > 1) Any encryption scheme that has all of the keys and methods hard
> > coded into SVN will be easy to decrypt by simply looking at the
> > source for SVN.
> >
> > 2) There is no reason to re-invent the wheel in SVN. Perfectly
> > good encryption schemes exist already.
> >
> > 3) The current CRAM-MD5 method requires that the unhashed password
> > be known. So any method of encrypting/hashing of the password must
> > be reversible (which leaves hashing out).
> >
> > 4) Any ROT-13 or BASE64 schemes provide no real security, just
> > obfuscation from cursory searches and accidental viewing.
> >
> > 5) In an ideal world the server would be a trusted location for
> > the passwords, but that mistakes and security breaches happen in
> > the real world.
> >
> > 6) Currently the preferred solutions are to use a different method
> > of authentication (Ex: ssh+svn) or to use randomly generated
> > passwords that are then cached on the client side.
> >
> > Ideally a complete solution would be best where an
> > administrator can add/delete users at will, but cannot decrypt the
> > user's passwords and where a user can update his or her password at
> > will. However, I do not think this is feasible.
> >
> > 7) Any method that SVN would use to decrypt the password would be
> > usable by the admin or root user if the SVN process had a different
> > privileges from the admin user.
> >
> > 8) Allowing the user any access to the configuration files from
> > the client is something that would be completely new to SVN and
> > might take a massive amount of development.
> >
> > I do think that there is an alternative that I have not seen
> > elsewhere in the mailing-lists. Going back to (3), the current
> > CRAM-MD5 method could be altered to an MD5-CRAM-MD5 method, where
> > the CRAM-MD5 is calculated on the MD5 of the password instead of
> > the password itself. This is the way that passwords longer than 64
> > characters are handled, except that I would like to allow the
> > storage of the MD5 sums in the passwd file.
> >
> > 9) ASCii passwords stored in the passwd file on the server
> > beginning with "md5:" would have the rest of the password checked
> > to see if the probability is high that it is an already computed
> > MD5 sum (all chars between 0-9 and A/a-F/f and proper length).
> > This would stop almost all false positives.
> >
> > 10) The MD5 portion of the password would then get converted into a
> > binary MD5 and passed onto the CRAM-MD5 portion of the code.
> >
> > On the client side:
> >
> > 11) ASCii password (pre-MD5) is entered, authentication goes
> > through normally and fails. Authentication is then attempted using
> > the MD5 of the ASCii password, which succeeds. User is asked if
> > the MD5-CRAM-MD5 method should always be used for this
> > server/repository.
> > Additionally/alternately a run-time switch or a configuration
> > option could be used. I've always been a fan of automatic
> > configuration.
> >
> > Okay, now tell me what obvious problem I forgot.
> >
> > --Jeff
> >
> > -------------------------------------------------------------------
> >-- To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org For
> > additional commands, e-mail: dev-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-21 05:42:47 CEST