[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Moving away from plain-text passwords in the server-side passwd file

From: Jeff Robins <jeffrobinssae_at_gmail.com>
Date: Tue, 20 May 2008 18:23:16 -0700

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
Received on 2008-05-21 03:23:44 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.