Svn – Subversion 1.6 + SASL : Only works with plaintext ‘userPassword’

encryptionsaslsvn

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 below:

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

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 passwd. i.e., if I were to run 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! I think, now I have only encrypted passwords…. only neither the Linux svn client nor the Windows TortoiseSVN client can connect to my repo anymore. They both present me with the user/pass challenge but that's as far as I get.


TLDR

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

Best Answer

This is hardly an answer but I'd like to point out that there are some sources that say explicitely that DIGEST-MD5 does not (and will never) support hashed passwords because it needs the plaintext password to do the challenge/response, like:

Other sources say otherwise: