Subversion password encryption

[Ma...@wellsfargo.com]

Hello,

I just got through reading the "How to report a bug" page but what I have is more of an enhancement request.  Not sure if it belongs here but I'll writeup either way just in case.

I am fairly new to Subversion but have nearly 20 years experience with ClearCase and Perforce strongly rooted in UNIX but in a mixed environment for quite some time.  Since I work for a large bank, we have pretty tight security requirements which are monitored by external groups.  We use Solaris, Redhat and Windows here.  Using the Apache 1.7.4 version of SVN, we ran into the obvious issue that SVN will store passwords in clear text.  We've been working with people at WANDisco to setup Gnome support for the password encryption and will have a solution in place shortly.  But, I have to say that the Gnome solution is less than desirable.  Issues being:

1. It requires that users to manage daemon processes which is fragile and leads to support queries.
2. Users must enter the gnome keyring password making cron job scheduling difficult.
3. The killall method of stopping gnome processes can knock out processes running for another login session.

There is more to talk about in the nuances of how Gmone works but I'll get more to the point which is: I'd like to request a simplified encryption scheme native to SVN even if it comes with some security caveats.  Something that:

1. Does not involve any external process or at least only one that the system manages and not the users.
2. Could be exactly what scheme is used for UNIX password encryption into the passwd file.
3. Could be some system where a file on the SVN server lists trusted machines so users from those machines don't have to enter a password.

I am not a security expert but I feel like we're going from zero (non-encrypted) to overkill (Gnome) without any intermediate choices.

It seems that this would be a fundamental enough issue that would interest lots of other SVN users.  I'm hoping that there is already some effort underway on this topic.

Thanks

Maurice Meyer

This message may contain confidential and/or privileged information, and is intended for the use of the addressee only. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

Re: Subversion password encryption

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

On Mon, Jun 25, 2012 at 3:30 PM,  <Ma...@wellsfargo.com> wrote:
> Hello,
>
> I just got through reading the "How to report a bug" page but what I have is
> more of an enhancement request.  Not sure if it belongs here but I'll
> writeup either way just in case.
>
> I am fairly new to Subversion but have nearly 20 years experience with
> ClearCase and Perforce strongly rooted in UNIX but in a mixed environment
> for quite some time.  Since I work for a large bank, we have pretty tight
> security requirements which are monitored by external groups.  We use
> Solaris, Redhat and Windows here.  Using the Apache 1.7.4 version of SVN, we
> ran into the obvious issue that SVN will store passwords in clear text.
> We've been working with people at WANDisco to setup Gnome support for the
> password encryption and will have a solution in place shortly.  But, I have
> to say that the Gnome solution is less than desirable.  Issues being:

It's also unreliable, since *any* aritrary client can and will store
the plain-text password for HTTP or HTTPS access *unless* you can
control the client setups enough to block the feature.

If you need to provide off-site Subversion access for clients you
don't have control over, It's a losing battle: go directly to svn+ssh,
which relies on SSH keys. Fools can still keep the SSH keys
unencrypted, but it separates access from other password based
authentication and helps prevent the use of merged authentication
technologies, such as Windows or Linux login passwords that should be
secure, wind up stored insecurely.

> 1. It requires that users to manage daemon processes which is fragile and
> leads to support queries.
> 2. Users must enter the gnome keyring password making cron job scheduling
> difficult.
> 3. The killall method of stopping gnome processes can knock out processes
> running for another login session.
>
> There is more to talk about in the nuances of how Gmone works but I'll get
> more to the point which is: I'd like to request a simplified encryption
> scheme native to SVN even if it comes with some security caveats.  Something
> that:

Some of the developers are working on this for version 1.8. That still
won't fix all the 1.7, 1.6, or older clients in th field, but it's a
start.

> 1. Does not involve any external process or at least only one that the
> system manages and not the users.
> 2. Could be exactly what scheme is used for UNIX password encryption into
> the passwd file.
> 3. Could be some system where a file on the SVN server lists trusted
> machines so users from those machines don't have to enter a password.

SSL keys or SH keys for svn+ssh.

> I am not a security expert but I feel like we're going from zero
> (non-encrypted) to overkill (Gnome) without any intermediate choices.

See above.

> It seems that this would be a fundamental enough issue that would interest
> lots of other SVN users.  I'm hoping that there is already some effort
> underway on this topic.

Historically, it's been treated much like passphrase free SSH keys.
It's been considered the user's problem that their client machine is
not secure. This, of course, breaks down in microseconds in any
environment where there's NFS version 3 or backup tapes of user's home
directories are commonplace.

RE: Subversion password encryption

[Ma...@wellsfargo.com]

Mark,

Thanks for the quick reply.  That confirmed my suspicions that the current UNIX encryption mechanisms are really just Gnome and KDE (GPG seems to be memory-resident which isn't quite enough for our needs.)  The built-in Encryption mentioned at the end of the document sounds very encouraging.  Hopefully that will get some momentum.

What I've done here is to slightly modify the use of Gnome so that users don't restart the Gnome/dbus processes every time they login.  This mitigates some of the issues with users managing these processes.  Not ideal but a little better than stop/starting Gnome all the time and provides the ability for cron jobs to connect to an already runing Gnome process with no password prompt.

Thanks again,

Maurice

-----Original Message-----
From: Mark Phippard [mailto:markphip@gmail.com] 
Sent: Monday, June 25, 2012 1:00 PM
To: Meyer, Maurice
Cc: users@subversion.apache.org
Subject: Re: Subversion password encryption

See:  http://wiki.apache.org/subversion/EncryptedPasswordStorage


On Mon, Jun 25, 2012 at 3:30 PM,  <Ma...@wellsfargo.com> wrote:
> Hello,
>
> I just got through reading the "How to report a bug" page but what I have is
> more of an enhancement request.  Not sure if it belongs here but I'll
> writeup either way just in case.
>
> I am fairly new to Subversion but have nearly 20 years experience with
> ClearCase and Perforce strongly rooted in UNIX but in a mixed environment
> for quite some time.  Since I work for a large bank, we have pretty tight
> security requirements which are monitored by external groups.  We use
> Solaris, Redhat and Windows here.  Using the Apache 1.7.4 version of SVN, we
> ran into the obvious issue that SVN will store passwords in clear text.
> We've been working with people at WANDisco to setup Gnome support for the
> password encryption and will have a solution in place shortly.  But, I have
> to say that the Gnome solution is less than desirable.  Issues being:
>
> 1. It requires that users to manage daemon processes which is fragile and
> leads to support queries.
> 2. Users must enter the gnome keyring password making cron job scheduling
> difficult.
> 3. The killall method of stopping gnome processes can knock out processes
> running for another login session.
>
> There is more to talk about in the nuances of how Gmone works but I'll get
> more to the point which is: I'd like to request a simplified encryption
> scheme native to SVN even if it comes with some security caveats.  Something
> that:
>
> 1. Does not involve any external process or at least only one that the
> system manages and not the users.
> 2. Could be exactly what scheme is used for UNIX password encryption into
> the passwd file.
> 3. Could be some system where a file on the SVN server lists trusted
> machines so users from those machines don't have to enter a password.
>
> I am not a security expert but I feel like we're going from zero
> (non-encrypted) to overkill (Gnome) without any intermediate choices.
>
> It seems that this would be a fundamental enough issue that would interest
> lots of other SVN users.  I'm hoping that there is already some effort
> underway on this topic.
>
> Thanks
>
> Maurice Meyer
>
> This message may contain confidential and/or privileged information, and is
> intended for the use of the addressee only. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose, or take any action based on this message or any information
> herein. If you have received this message in error, please advise the sender
> immediately by reply e-mail and delete this message. Thank you for your
> cooperation.
>
>
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Subversion password encryption

[Mark Phippard <ma...@gmail.com>]

See:  http://wiki.apache.org/subversion/EncryptedPasswordStorage


On Mon, Jun 25, 2012 at 3:30 PM,  <Ma...@wellsfargo.com> wrote:
> Hello,
>
> I just got through reading the "How to report a bug" page but what I have is
> more of an enhancement request.  Not sure if it belongs here but I'll
> writeup either way just in case.
>
> I am fairly new to Subversion but have nearly 20 years experience with
> ClearCase and Perforce strongly rooted in UNIX but in a mixed environment
> for quite some time.  Since I work for a large bank, we have pretty tight
> security requirements which are monitored by external groups.  We use
> Solaris, Redhat and Windows here.  Using the Apache 1.7.4 version of SVN, we
> ran into the obvious issue that SVN will store passwords in clear text.
> We've been working with people at WANDisco to setup Gnome support for the
> password encryption and will have a solution in place shortly.  But, I have
> to say that the Gnome solution is less than desirable.  Issues being:
>
> 1. It requires that users to manage daemon processes which is fragile and
> leads to support queries.
> 2. Users must enter the gnome keyring password making cron job scheduling
> difficult.
> 3. The killall method of stopping gnome processes can knock out processes
> running for another login session.
>
> There is more to talk about in the nuances of how Gmone works but I'll get
> more to the point which is: I'd like to request a simplified encryption
> scheme native to SVN even if it comes with some security caveats.  Something
> that:
>
> 1. Does not involve any external process or at least only one that the
> system manages and not the users.
> 2. Could be exactly what scheme is used for UNIX password encryption into
> the passwd file.
> 3. Could be some system where a file on the SVN server lists trusted
> machines so users from those machines don't have to enter a password.
>
> I am not a security expert but I feel like we're going from zero
> (non-encrypted) to overkill (Gnome) without any intermediate choices.
>
> It seems that this would be a fundamental enough issue that would interest
> lots of other SVN users.  I'm hoping that there is already some effort
> underway on this topic.
>
> Thanks
>
> Maurice Meyer
>
> This message may contain confidential and/or privileged information, and is
> intended for the use of the addressee only. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose, or take any action based on this message or any information
> herein. If you have received this message in error, please advise the sender
> immediately by reply e-mail and delete this message. Thank you for your
> cooperation.
>
>
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/