You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2008/05/21 04:14:07 UTC
Re: Moving away from plain-text passwords in the server-side
passwd file
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. To the extent that it 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.
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.
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. 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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Jeff Robins <je...@gmail.com>.
On Thursday 22 May 2008 9:41:19 am Martin Furter wrote:
> On Thu, 22 May 2008, Stefan Sperling wrote:
> > On Wed, May 21, 2008 at 09:27:53PM -0700, Jeff Robins wrote:
> >> How hard does anyone think it would it be to add TLS, maybe an
> >> estimation in "man-hours"? I am willing to spend some time on it,
> >> but I don't know how fast I could get it done. My free time is
> >> limited per day, but I hopefully have a lot of days left in my
> >> life.
> >
> > Why not just spend a few hours to find out how much work it is? :)
> >
> > I've found that starting to work on something is a good way to get
> > a rough idea of how complex the task at hand is, at minimum.
> > Just theorizing about a task will likely make me overlook important
> > details that add to its complexity.
> >
> > Glad you want to work on this,
> > Stefan
>
> Some work has been done a few years ago. I don't know how much work
> it is to port it to the current trunk.
>
> http://svn.haxx.se/dev/archive-2004-10/1091.shtml
>
> Martin
Thanks. I'll start by looking at that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd
file
Posted by Martin Furter <mf...@rola.ch>.
On Thu, 22 May 2008, Stefan Sperling wrote:
> On Wed, May 21, 2008 at 09:27:53PM -0700, Jeff Robins wrote:
>> How hard does anyone think it would it be to add TLS, maybe an
>> estimation in "man-hours"? I am willing to spend some time on it, but
>> I don't know how fast I could get it done. My free time is limited per
>> day, but I hopefully have a lot of days left in my life.
>
> Why not just spend a few hours to find out how much work it is? :)
>
> I've found that starting to work on something is a good way to get
> a rough idea of how complex the task at hand is, at minimum.
> Just theorizing about a task will likely make me overlook important
> details that add to its complexity.
>
> Glad you want to work on this,
> Stefan
Some work has been done a few years ago. I don't know how much work it is
to port it to the current trunk.
http://svn.haxx.se/dev/archive-2004-10/1091.shtml
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side
passwd file
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 21, 2008 at 09:27:53PM -0700, Jeff Robins wrote:
> How hard does anyone think it would it be to add TLS, maybe an
> estimation in "man-hours"? I am willing to spend some time on it, but
> I don't know how fast I could get it done. My free time is limited per
> day, but I hopefully have a lot of days left in my life.
Why not just spend a few hours to find out how much work it is? :)
I've found that starting to work on something is a good way to get
a rough idea of how complex the task at hand is, at minimum.
Just theorizing about a task will likely make me overlook important
details that add to its complexity.
Glad you want to work on this,
Stefan
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Jeff Robins <je...@gmail.com>.
On Wednesday 21 May 2008 10:11:52 am Eric Gillespie wrote:
> "Mark Phippard" <ma...@gmail.com> writes:
> > mechanisms we support. It would be doable to write code that
> > validates a username and password received from a client, but for
> > this to work those have to be sent in the clear over the network.
> > Those options are turned off in Subversion. Our docs say it is
> > because we do not use TLS. If the server does not know the
> > plaintext password
>
> We need TLS support, absolutely. This would have been a nice
> summer of code project ;->.
>
How hard does anyone think it would it be to add TLS, maybe an
estimation in "man-hours"? I am willing to spend some time on it, but
I don't know how fast I could get it done. My free time is limited per
day, but I hopefully have a lot of days left in my life.
> > I am basically saying we need to be clear what you can actually do
> > with SASL today.
>
> Sounds like we're in agreement, cool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, May 21, 2008 at 10:20 AM, Greg Hudson <gh...@mit.edu> wrote:
> On Wed, 2008-05-21 at 12:40 -0400, Mark Phippard wrote:
>> If the server does not know the plaintext password
>> for a user then you cannot use CRAM-MD5 or DIGEST-MD5 auth mechanisms.
>
> With DIGEST-MD5 it's possible for the server to know only an
> intermediate hash of the password. Unfortunately, I don't think Cyrus
> SASL supports that. (Not sure, though.)
Cyrus SASL does support DIGEST-MD5; I forget if it supports only
knowing the hash, though.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side
passwd file
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2008-05-21 at 12:40 -0400, Mark Phippard wrote:
> If the server does not know the plaintext password
> for a user then you cannot use CRAM-MD5 or DIGEST-MD5 auth mechanisms.
With DIGEST-MD5 it's possible for the server to know only an
intermediate hash of the password. Unfortunately, I don't think Cyrus
SASL supports that. (Not sure, though.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Mark Phippard" <ma...@gmail.com> writes:
> mechanisms we support. It would be doable to write code that
> validates a username and password received from a client, but for this
> to work those have to be sent in the clear over the network. Those
> options are turned off in Subversion. Our docs say it is because we
> do not use TLS. If the server does not know the plaintext password
We need TLS support, absolutely. This would have been a nice
summer of code project ;->.
> I am basically saying we need to be clear what you can actually do
> with SASL today.
Sounds like we're in agreement, cool.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 21, 2008 at 12:12 PM, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "Mark Phippard" <ma...@gmail.com> writes:
>
>> The reality is that you do not have to spend very long really trying
>> to use Cyrus SASL to see that it is pretty half-assed. In particular
>> its support for Windows is virtually non-existent.
>
> The former does not follow from the latter.
I was using Windows as an easy example and I do think it is pretty
significant. The documentation is poor overall and it is not clear
what pieces are fully implemented and how you use them. Especially
across platforms.
>> So while I think we have done the right thing in not inventing our own
>> security, I am not sure that SASL is really the answer either.
>
> And what is?
>
> Cyrus SASL is a good answer, and those who seek Windows support
> should step up and provide it. From what I've seen poking inside
> Cyrus SASL, it's not heinously Unix-specific; I think it just
> lacks testing and maintenance on Windows.
I agree with this. I am simply saying that we have led users to
believe that this is the answer for all svnserve authentication
options. I think it is probably our only hope but it is clear that
Cyrus SASL needs work. It is also not at all clear to me how you
could build support for Windows authentication using the auth
mechanisms we support. It would be doable to write code that
validates a username and password received from a client, but for this
to work those have to be sent in the clear over the network. Those
options are turned off in Subversion. Our docs say it is because we
do not use TLS. If the server does not know the plaintext password
for a user then you cannot use CRAM-MD5 or DIGEST-MD5 auth mechanisms.
I am not sure if Kerberos could be used or not, but that is another
area where Windows support is weak.
I am basically saying we need to be clear what you can actually do
with SASL today.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Mark Phippard" <ma...@gmail.com> writes:
> The reality is that you do not have to spend very long really trying
> to use Cyrus SASL to see that it is pretty half-assed. In particular
> its support for Windows is virtually non-existent.
The former does not follow from the latter.
> So while I think we have done the right thing in not inventing our own
> security, I am not sure that SASL is really the answer either.
And what is?
Cyrus SASL is a good answer, and those who seek Windows support
should step up and provide it. From what I've seen poking inside
Cyrus SASL, it's not heinously Unix-specific; I think it just
lacks testing and maintenance on Windows.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, May 21, 2008 at 11:04 AM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> On Wed, May 21, 2008 at 2:30 AM, David Glasser <gl...@davidglasser.net> wrote:
>
>> See http://svn.collab.net/repos/svn/trunk/notes/sasl.txt for more
>> information on using SASL with svnserve.
>
> I've documented it in the svn 1.5 book as well. Really, the barrier
> to entry isn't very high. :-)
>
> I agree with ghudson and glasser here: I do not want to see
> Subversion start inventing its own half-assed security features. It's
> a waste of energy, a reinvention of the wheel, and a maintenance
> burden. We should use the 'standard library' -- written by security
> experts, depended on by millions -- to do our security.
I also pretty much agree with this. That said, I do think there is a
problem with SASL. We like to portray it as "the answer" to this
question. For example, not to pick on Ben, but you essentially speak
of SASL when you say:
"written by security experts, depended on by millions"
The reality is that you do not have to spend very long really trying
to use Cyrus SASL to see that it is pretty half-assed. In particular
its support for Windows is virtually non-existent. I see know
possibility to use it and allow users to use their existing Windows
domain credentials, which is going to be a pretty common request.
The SASLDB feature works, but from what I read it seems like you have
simply moved your plain text passwords from a text file into a BDB
database. I am not sure if SASL makes any claims on the data in that
file being secure.
So while I think we have done the right thing in not inventing our own
security, I am not sure that SASL is really the answer either.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Wed, May 21, 2008 at 2:30 AM, David Glasser <gl...@davidglasser.net> wrote:
> See http://svn.collab.net/repos/svn/trunk/notes/sasl.txt for more
> information on using SASL with svnserve.
I've documented it in the svn 1.5 book as well. Really, the barrier
to entry isn't very high. :-)
I agree with ghudson and glasser here: I do not want to see
Subversion start inventing its own half-assed security features. It's
a waste of energy, a reinvention of the wheel, and a maintenance
burden. We should use the 'standard library' -- written by security
experts, depended on by millions -- to do our security.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by David Glasser <gl...@davidglasser.net>.
On Wed, May 21, 2008 at 12:10 AM, Jeff Robins <je...@gmail.com> wrote:
> 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.
I would hope that a boss would be more convinced by "this uses the
industry-standard open source SASL library for authentication" than
"security is provided by some half-assed feature that people who know
more about version control than security coded up to help people who
don't feel like installing the library that already does the right
thing".
See http://svn.collab.net/repos/svn/trunk/notes/sasl.txt for more
information on using SASL with svnserve.
(And of course there are a variety of authentication options for
Apache with mod_dav_svn.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Moving away from plain-text passwords in the server-side passwd file
Posted by Jeff Robins <je...@gmail.com>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org