svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

["Donner, Sean P" <se...@lmco.com>]

I'm attempting to setup svnserve with SASL support on my Slackware 13.1 server and after
some trial and error I'm able to get it to work with the configuration listed at the end of this
post.

You'll notice that the output of sasldblistusers2 shows my test user as having both an
encrypted cmusaslsecretOTP password as well as a plain text userPassword. i.e., if I were to
run the command ‘strings /etc/sasl2/my_sasldb’ I would see the test users' password in
plaintext. These two password entries were created with the following subversion-book
recommended command:

saslpasswd2 -c -f /etc/sasl2/my_sasldb -u myrepo test

After reading man saslpasswd2 I see the following option:

"-n Don't set the plaintext userPassword property for the user. Only mechanism-specific
secrets will be set (e.g. OTP, SRP)"

This is exactly what I want to do, suppress the plain text password and only use the
mechanism-specific secret (OTP in my case). So I clear out /etc/sasl2/my_sasldb and rerun
saslpasswd2 as:

saslpasswd2 -n -c -f /etc/sasl2/my_sasldb -u myrepo test

I then follow it up with a sasldblistusers2 and I see:

$ sasldblistusers2 -f /etc/sasl2/my_sasldb
test@myrepo: cmusaslsecretOTP

Perfect! Now I have only encrypted passwords in my sasldb.... only neither the Linux svn
client nor the Windows TortoiseSVN client can connect to my repo anymore. They both
present me with an endless loop of user/pass challenge. As soon as I rerun saslpasswd2
without the '-n' flag, everything works again.

So, what’s the point of svnserve supporting SASL if my sasldb must store its passwords in
plaintext to work?

Thanks,
-Sean

============CONFIGUR​ATION===============​=

-----------------------------
svnserve.conf
-----------------------------
[general]
anon-access = read
auth-access = write
realm = myrepo

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

-----------------------------
/etc/sasl2/svn.conf
-----------------------------
pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/sasl2/my_sasldb
mech_list: DIGEST-MD5

-----------------------------
sasldb users
-----------------------------
$ sasldblistusers2 -f /etc/sasl2/my_sasldb
test@myrepo: cmusaslsecretOTP
test@myrepo: userPassword

Re: svnserve + SASL: Only works with plaintext 'userPassword', sowhat's the point?

[Ted Stern <do...@gmail.com>]

On 26 Jan 2011 23:51:26 -0800, Nico Kadel-Garcia wrote:
>
> On Wed, Jan 26, 2011 at 9:26 PM, Stefan Sperling <st...@elego.de> wrote:
>> On Wed, Jan 26, 2011 at 07:08:55PM -0700, Donner, Sean P wrote:
>>> > It's because of how CramMD5 works.
>>> >
>>> > "The server needs access to the users' plain text passwords."
>>> > http://en.wikipedia.org/wiki/CRAM-MD5
>>> >
>>> > Stefan
>>>
>>> Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
>>> 'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
>>> 'use-sasl = true' to get this functionality.
>>
>> That's correct. But you can still configure SASL do to CRAM-MD5.
>> So there might be a bug in svn.
>> Maybe it still assumes that plaintext passwords will always be present.
>>
>>> So my original question stands as
>>> to what SASL is buying us when it still requires plain-text passwords to be
>>> stored on the server?
>>
>> Unfortunately the sasl stuff is not being maintained very actively.
>> The developers who wrote it aren't active anymore.
>> There are a couple of outstanding issues (some with half-done patches
>> floating around) that haven't been addressed due to lack of interest
>> and resources.
>>
>> So if you want to help out with investigating this problem more closely
>> and possibly also help with fixing this the Subversion project would
>> be grateful.
>
> Or switch to svn+ssh for SSH key based access, which has other
> advantages.

I use svn+ssh, multiplexed through a single account.  I enjoy the
advantages this provides.

One thing I do, though, may not be the most secure.  I'm wondering
about the risks of not starting svnserve directly in the svnuser's
~/.ssh/authorized_keys file, but instead using a wrapper script.  What
I put in the authorized_keys file is something like

     command="/home/svnuser/bin/svnserve_wrapper \
     full.user.name",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty \
     ssh-rsa <long public key> useraddress@someplace.com

     (line breaks added for clarity)

In my svnserve_wrapper, I start up svnserve as follows:

,----[ svnserve_wrapper ]
| #!/bin/bash
| # This is a wrapper for the svnserve command.
| #
| # Adjust parameters here
| SVNHOST="hostname.someplace.com"
| SVNPATH=/path/to/Collabnet_Subversion/bin
| SVNROOT=/path/to/svnroot
| #
| # Here's why we're running svnserve via a wrapper:
| # It allows us to
| # * Make changes in a single location instead of having to
| #   edit ~svnuser/.ssh/authorized_keys
| # * Enforce access through a single host
| # * Set up correct umask
| # * Change PATH to find correct version of svnserve
| # * Set up path to svn repository
| # * Log subversion access
| #
| # Enforce single host:
| [[ "$(/bin/hostname)" = "$SVNHOST" ]] || {
|    echo "Unauthorized host:  svn+ssh access permitted only through $SVNHOST"
|    exit 1
| }
| 
| umask 077
| export PATH=$SVNPATH:$PATH
| 
| # Do logging
| # Format is YYYY-MM-DD-HH:MM:SS userid svn-args
| echo $(date -u '+%F-%X') "$@" "$SSH_CLIENT" >>/home/svnuser/svnlogs/`date "+%Y-%m"`
| 
| # extract the user id
| userid=$1
| shift
| 
| # execute svnserve in correct format
| exec svnserve -t --tunnel-user=$userid -r $SVNROOT ${1+"$@"}
`----

Are there security risks in starting up a shell script instead of a
compiled binary?

Ted
-- 
 Frango ut patefaciam -- I break so that I may reveal

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Nico Kadel-Garcia <nk...@gmail.com>]

On Wed, Jan 26, 2011 at 9:26 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Jan 26, 2011 at 07:08:55PM -0700, Donner, Sean P wrote:
>> > It's because of how CramMD5 works.
>> >
>> > "The server needs access to the users' plain text passwords."
>> > http://en.wikipedia.org/wiki/CRAM-MD5
>> >
>> > Stefan
>>
>> Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
>> 'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
>> 'use-sasl = true' to get this functionality.
>
> That's correct. But you can still configure SASL do to CRAM-MD5.
> So there might be a bug in svn.
> Maybe it still assumes that plaintext passwords will always be present.
>
>> So my original question stands as
>> to what SASL is buying us when it still requires plain-text passwords to be
>> stored on the server?
>
> Unfortunately the sasl stuff is not being maintained very actively.
> The developers who wrote it aren't active anymore.
> There are a couple of outstanding issues (some with half-done patches
> floating around) that haven't been addressed due to lack of interest
> and resources.
>
> So if you want to help out with investigating this problem more closely
> and possibly also help with fixing this the Subversion project would
> be grateful.

Or switch to svn+ssh for SSH key based access, which has other advantages.

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Stefan Sperling <st...@elego.de>]

On Wed, Jan 26, 2011 at 07:08:55PM -0700, Donner, Sean P wrote:
> > It's because of how CramMD5 works.
> >
> > "The server needs access to the users' plain text passwords."
> > http://en.wikipedia.org/wiki/CRAM-MD5
> >
> > Stefan
> 
> Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
> 'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
> 'use-sasl = true' to get this functionality.

That's correct. But you can still configure SASL do to CRAM-MD5.
So there might be a bug in svn.
Maybe it still assumes that plaintext passwords will always be present.

> So my original question stands as
> to what SASL is buying us when it still requires plain-text passwords to be
> stored on the server?

Unfortunately the sasl stuff is not being maintained very actively.
The developers who wrote it aren't active anymore.
There are a couple of outstanding issues (some with half-done patches
floating around) that haven't been addressed due to lack of interest
and resources.

So if you want to help out with investigating this problem more closely
and possibly also help with fixing this the Subversion project would
be grateful.

Stefan

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

["Donner, Sean P" <se...@lmco.com>]

> It's because of how CramMD5 works.
>
> "The server needs access to the users' plain text passwords."
> http://en.wikipedia.org/wiki/CRAM-MD5
>
> Stefan

Perhaps I'm wrong, but I was under the impression that the 1.6.x version of
'svnserve' natively supports CRAM-MD5; meaning you *don't* need to set
'use-sasl = true' to get this functionality.  So my original question stands as
to what SASL is buying us when it still requires plain-text passwords to be
stored on the server?

-Sean

Re: svnserve + SASL: Only works with plaintext 'userPassword', so what's the point?

[Stefan Sperling <st...@elego.de>]

On Tue, Jan 25, 2011 at 12:51:12PM -0700, Donner, Sean P wrote:
> I'm attempting to setup svnserve with SASL support on my Slackware 13.1 server and after
> some trial and error I'm able to get it to work with the configuration listed at the end of this
> post.
> 
> You'll notice that the output of sasldblistusers2 shows my test user as having both an
> encrypted cmusaslsecretOTP password as well as a plain text userPassword. i.e., if I were to
> run the command ‘strings /etc/sasl2/my_sasldb’ I would see the test users' password in
> plaintext. These two password entries were created with the following subversion-book
> recommended command:
> 
> saslpasswd2 -c -f /etc/sasl2/my_sasldb -u myrepo test
> 
> After reading man saslpasswd2 I see the following option:
> 
> "-n Don't set the plaintext userPassword property for the user. Only mechanism-specific
> secrets will be set (e.g. OTP, SRP)"
> 
> This is exactly what I want to do, suppress the plain text password and only use the
> mechanism-specific secret (OTP in my case). So I clear out /etc/sasl2/my_sasldb and rerun
> saslpasswd2 as:
> 
> saslpasswd2 -n -c -f /etc/sasl2/my_sasldb -u myrepo test
> 
> I then follow it up with a sasldblistusers2 and I see:
> 
> $ sasldblistusers2 -f /etc/sasl2/my_sasldb
> test@myrepo: cmusaslsecretOTP
> 
> Perfect! Now I have only encrypted passwords in my sasldb.... only neither the Linux svn
> client nor the Windows TortoiseSVN client can connect to my repo anymore. They both
> present me with an endless loop of user/pass challenge. As soon as I rerun saslpasswd2
> without the '-n' flag, everything works again.
> 
> So, what’s the point of svnserve supporting SASL if my sasldb must store its passwords in
> plaintext to work?

It's because of how CramMD5 works.

"The server needs access to the users' plain text passwords."
http://en.wikipedia.org/wiki/CRAM-MD5

Stefan