Subversion 1.5 supports SASL for svnserve authentication.
--dave
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
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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 03:29:13 CEST