On Tuesday 20 May 2008 9:14:07 pm Greg Hudson wrote:
> On Tue, 2008-05-20 at 20:42 -0700, Jeff Robins wrote:
> > 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.
>
> First and foremost, Subversion doesn't want to implement more
> security code than it has to. (Or at least, when I designed svnserve
> that was a goal.) svnserve's built-in password support was a stopgap
> and was intended to be as simple as possible.
> presents deployment issues (and there are many besides the most
> obvious), the best solution is to rely on third-party code, not to
> flesh out the stopgap.
>
This should only be a small amount of code added to cram.c, which is the
only file I have looked at so far. I wouldn't think that the code to
read the config file and for the authentication retry should be too
long. I am willing to do the coding, I just don't want to spend the
time on a patch that will not be received well.
> I'm not sure what you mean by an "external authentication manager."
> Cyrus SASL is a library; it does not (to my knowledge) require an
> external network entity to do authentication, if that's what you
> mean.
>
I'm sorry, I didn't have a lot of time to look at the SASL
documentation, but I got the impression that it was made to handle the
encryption/hashing aspect of authentication. Both sides agree to
transport a password in some fashion (encryption or hashing) and then
SASL does the encryption/hashing and comparison. The program handles
the actual communication. The passwords still have to be stored
somewhere else in some format. They can be stored in the passwd file
in plain-text or stored by a third-party authentication
program/system/manager (which can be on the same machine or a different
machine). I could definitely have this wrong, but that was the
impression I got.
> There are a few other issues with your proposal--not necessarily
> fatal flaws:
>
> 1. Your proposal turns the MD5 of the password into the password
> itself. That prevents the typed password from being recovered from
> the server and used with dissimilar systems, but doesn't prevent the
> MD5 of the password from being used with other systems using the same
> technique. So it fails the categorical imperative--if Subversion
> alone does this, it has some value, but if everyone does it, it
> doesn't solve any problems.
The MD5 of the password is only turned into the password on the server
side. If the code in cram.c only allows "md5:8120..3" to be chnaged
into straight binary MD5 for the server, then the actual password is
still needed on the client side. Of course the code could be changed,
but then you would still need to know the stored MD5 value from the
passwd file and, currently, if you can get the contents passwd file,
then you have all of the passwords anyway.
You will still loose the security of the repository if the contents of
the passwd file is known, but you will not lose the security of the
passwords themselves. This is the same idea behind using MD5 passwords
in the shadow file in *NIX systems. Reduced access to the shadow file
and the MD5 SALT increases the security even more.
> Hashing the password together with
> something else (like the auth realm, or the string "svn") fixes this
> issue but further increases the amount of complexity we don't want in
> Subversion's code.
>
Those would be more secure alternatives, but I was just looking to
protect the actual password.
> 2. You're inventing a new authentication protocol. ra_svn uses the
> SASL protocol framework (whether or not it uses the Cyrus SASL
> implementation); your proposal would be departing from that standard.
>
This would be a departure, but it shouldn't break compatibility except
for the small number of cases where someone is already using "md5:" +
an MD5 hash as a password. In all other cases svnserve would respond
normally. The client would respond in a non-standard way if the login
failed the first time, which would necessitate the use of a switch.
Logins using the *NIX password are handled using a different mechanism
because it is stored as a SALT+MD5 hash in the shadow file. The
password is sent encrypted to the server, the server decrypts it, then
applies the SALT+MD5 hash and compares the values (as I understand it).
> 3. Your proposal requires supply a tool to manage svnserve passwd
> files (like httpd's "htpasswd" command). Part of the reason for
> being so simplistic is to avoid having to provide another user-facing
> tool.
All of the functions are there for the password to MD5 conversion. A
simple tool to take the input and spit out a MD5 hash wouldn't be
difficult. It could be added as a switch to svn and/or svnadmin. It
would add some complexity to the Subversion solution, but I would think
that this would add a feasible choice for users that don't want to
store the passwords in plain-text, but don't want to setup a SASL
implementation with passwords somehow encrypted and then decrypted when
needed or a secure transfer protocol so that the client can send the
hashed password to the server.
As I said, I didn't have much time to look at the SASL documentation so
please bear with me if I got something wrong. I'm not trying to pester
you just come up with a good solution, if it turns out that one is
needed.
My current situation is that I want to pitch this to my boss, but he
won't take it with plain-text passwords on the server. The server runs
IIS and the sys-admin isn't likely to spend much time setting this up
if it's only for one small part of the company. The easiest way to run
this would be in stand-alone svnserve mode, but with some type of
hashed/encrypted passwords.
---------------------------------------------------------------------
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 09:10:58 CEST