Can svnserve read an encrypted password file?

[vinay i]

Hi All
I was wondering if it is possible to keep the password file in an encrypted
format. This would help in maintaining the passwords securely. Any thoughts?
Or is there any other option available?

Thanks
I Vinay

[Paul Koning]

vinay> Hi All I was wondering if it is possible to keep the password
vinay> file in an encrypted format. This would help in maintaining
vinay> the passwords securely.

The client needs the plaintext password, so it would have to decrypt
the password if it's stored encrypted, which means it needs to know
the key, which means someone could read that key out of the client.
So encrypting adds no security -- that's why the option isn't there.

More precisely, encryption would mislead some people into believing
there is security when there isn't, which is worse than not having
encryption.

paul

[Stefan Sperling]

Post by Paul Koning
vinay> Hi All I was wondering if it is possible to keep the password
vinay> file in an encrypted format. This would help in maintaining
vinay> the passwords securely.
The client needs the plaintext password,

The question was about svnserve, not the client.
(See the message subject.)

svnserve cannot yet store passwords in encrypted form, AFAIK.

See also the (long) thread starting at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=67919

and this message in particular:
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=67949

Post by Paul Koning
so it would have to decrypt
the password if it's stored encrypted, which means it needs to know
the key, which means someone could read that key out of the client.
So encrypting adds no security -- that's why the option isn't there.

The option of encrypting passwords on the client side has been
present on Windows and Mac OS X for quite some time now.

In Subversion 1.6 encrypting passwords on the client side will also
be possible on Linux/UNIX.
See http://subversion.tigris.org/faq.html#plaintext-passwords

Post by Paul Koning
More precisely, encryption would mislead some people into believing
there is security when there isn't, which is worse than not having
encryption.

I don't buy that argument. For some people, storing a password on
disk in plaintext is the weakest link in the chain. Telling them
that was not so does not solve their problem.

Encrypting passwords on disk with the help of system services like
Gnome Keyring and Kwallet, as Subversion 1.6 will be able to do,
is a very reasonable approach IMHO.

Stefan

[Mark K]

On Thu, 28 Aug 2008 19:21:40 +0200

Post by Stefan Sperling

Post by Paul Koning
vinay> Hi All I was wondering if it is possible to keep the
vinay> password file in an encrypted format. This would help in
vinay> maintaining the passwords securely.
The client needs the plaintext password,

The question was about svnserve, not the client.
(See the message subject.)
svnserve cannot yet store passwords in encrypted form, AFAIK.
See also the (long) thread starting at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=67919
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=67949

Post by Paul Koning
so it would have to decrypt
the password if it's stored encrypted, which means it needs to know
the key, which means someone could read that key out of the client.
So encrypting adds no security -- that's why the option isn't there.

The option of encrypting passwords on the client side has been
present on Windows and Mac OS X for quite some time now.
In Subversion 1.6 encrypting passwords on the client side will also
be possible on Linux/UNIX.
See http://subversion.tigris.org/faq.html#plaintext-passwords

Post by Paul Koning
More precisely, encryption would mislead some people into believing
there is security when there isn't, which is worse than not having
encryption.

I don't buy that argument. For some people, storing a password on
disk in plaintext is the weakest link in the chain. Telling them
that was not so does not solve their problem.
Encrypting passwords on disk with the help of system services like
Gnome Keyring and Kwallet, as Subversion 1.6 will be able to do,
is a very reasonable approach IMHO.
Stefan

AFAIK the preferred gnome keyring thing is now seahorse
(http://www.gnome.org/projects/seahorse/index.html). One could just
use svn+ssh with keys and avoid the whole plaintext password issue.

Also, wouldn't svnserve+sasl be able to solve the complaint of having
plain text passwords stored on the server side?

[Alec Kloss]

On 2008-08-28 16:02, Mark K wrote:
[chop]

Post by Mark K
AFAIK the preferred gnome keyring thing is now seahorse
(http://www.gnome.org/projects/seahorse/index.html). One could just
use svn+ssh with keys and avoid the whole plaintext password issue.

This gets messy if you've got Windows clients. Either they need to
have their private key unencrypted which is worse than having
subversion cache their password in the magic place Microsoft
provides, or they need to try to get pagent and putty to place nice
with their client. Certainly possible, but certainly not easy.

Post by Mark K
Also, wouldn't svnserve+sasl be able to solve the complaint of having
plain text passwords stored on the server side?

Pretty much only if you're using (my favorite) gssapi with sasl.
Just about everything else in sasl requires either clear-text
transmission of the password or clear-text storage of the password
on the server. It's probably still slightly better to use sasl
because the authentication is normally offloaded to a specialized
authentication server so there's sort-of less to audit.

[Grigory V. Kareev]

On Thu, 28 Aug 2008 16:35:25 -0500
Alec Kloss <***@oracle.com> wrote:

[skip]

Post by Alec Kloss

Post by Mark K
Also, wouldn't svnserve+sasl be able to solve the complaint of having
plain text passwords stored on the server side?

Pretty much only if you're using (my favorite) gssapi with sasl.
Just about everything else in sasl requires either clear-text
transmission of the password or clear-text storage of the password
on the server. It's probably still slightly better to use sasl
because the authentication is normally offloaded to a specialized
authentication server so there's sort-of less to audit.

If you host only one repo using svnserve, then sasl+ldap
thing will work too. You need to setup sasl to provide only DIGEST-MD5
auth method in svnserve and setup your ldap users properly keeping
http://southbrain.com/south/2008/08/cmusaslsecretcrammd5-cmusaslse.html
in mind.

If you want to host multiple repositories using one svnserve process,
cleartext passwords stored either in ldap, sasldb or svnserve db
is the only option currently, IMO.

Possible solutions are:
a) TLS support for svn client and svnserve (in this case we can use
sasl cleartext password transmitting auth methods like PLAIN or LOGIN
and svnserve will be able to do checks against any encrypted passwords db)
b) alter svnserve internal CRAM-MD5 auth method and make it work with
stored passwords hashes as described here:
http://southbrain.com/south/2008/08/cmusaslsecretcrammd5-cmusaslse.html
c) add svnserve config or command line option to disable internal CRAM-MD5 mech
and let the sasl do all checks

[Stefan Sperling]

Post by Grigory V. Kareev
If you want to host multiple repositories using one svnserve process,
cleartext passwords stored either in ldap, sasldb or svnserve db
is the only option currently, IMO.
a) TLS support for svn client and svnserve (in this case we can use
sasl cleartext password transmitting auth methods like PLAIN or LOGIN
and svnserve will be able to do checks against any encrypted passwords db)
b) alter svnserve internal CRAM-MD5 auth method and make it work with
http://southbrain.com/south/2008/08/cmusaslsecretcrammd5-cmusaslse.html
c) add svnserve config or command line option to disable internal CRAM-MD5 mech
and let the sasl do all checks

I would not expect good patches which implement either a, b, or c
to be rejected :)

Stefan

[Dave Lawrence]

Going back to the original question - it's worth noting the Apache can
store MD5 encrypted passwords. So to the OP, maybe using Apache instead
is the answer (especially if you're only just starting out). It's not
that much more complicated to set up.

[Matthias Fechner]

Hi,

why not use ssh with private/public keys or authentification with apache
and htdigest?

In both cases no password must be stored in clear text or is not
transmitted in clear text.

Bye,
Matthias

[Alec Kloss]

Post by Stefan Sperling

Post by Grigory V. Kareev
If you want to host multiple repositories using one svnserve process,
cleartext passwords stored either in ldap, sasldb or svnserve db
is the only option currently, IMO.
a) TLS support for svn client and svnserve (in this case we can use
sasl cleartext password transmitting auth methods like PLAIN or LOGIN
and svnserve will be able to do checks against any encrypted passwords db)
b) alter svnserve internal CRAM-MD5 auth method and make it work with
http://southbrain.com/south/2008/08/cmusaslsecretcrammd5-cmusaslse.html
c) add svnserve config or command line option to disable internal CRAM-MD5 mech
and let the sasl do all checks

I would not expect good patches which implement either a, b, or c
to be rejected :)

I've thought about doing (a). There was a draft once upon a time
for adding TLS to SASL itself but I don't think it went anywhere.
One could either implement such a thing, in which case this becomes
purely an issue for SASL, or one could implement "svns://", a
TLS-tunneled svn protocol connection. "svns://" wouldn't require
a new SASL mechanism so would probably be quicker to get off the
ground, but there are some real perks to having SASL in general
support TLS. Any thoughts about what would be preferred for
Subversion?

I'd never heard of (b) prior to now. It makes some sense, but I
think you'd want to get the SASL mechanisms extended to handle the
idea of a "hashed password" CRAM-MD5 secret, or else I fear the
interoperability problems will be substantial. Also note that
these hashed keys become password-equivalent so to some people,
there's not much of an improvement here. (As I understand it, krb5
justifies the password equivalents by only storing them on the KDC,
and then hardening the KDC to prevent disclosure.)