Re: Passwords, Security, and Performance

Not to minimize your analysis, but wouldn't any place that takes passwords
seriously use svn+ssh instead, such that the server never sees them (ie.
*real* single signon, with Kerberos for example...) and to properly delegate
security concerns to the people who truly obsess over them?

On Nov 2, 2008 1:20 PM, "Mark Mielke" <mark_at_mark.mielke.cc> wrote:

Hi all:

I'm happy to see that Subversion is closing in completing some features that
will make it usable in places beyond the original target audience (CVS
users). Merge tracking and the SVN 1.6 features to improve security are
important to me and make the difference between Subversion being not usable,
and usable in some environments.

An area that Subversion is currently "poor" in my opinion is its handling of
passwords. There are two components to this - the first is security and the
second is performance.

Starting with security:

The FAQ and documentation recognizes that some users cannot or do not wish
to store passwords to disk. Subversion has three models: 1) Store passwords,
or 2) Do not store passwords, 3) Subversion 1.6 on UNIX, and Subversion
today for Windows and MacOS X improve on this by providing a third option -
store passwords in an encrypted key ring.

For many groups this third option will be the preference and provides a good
compromise between 1) and 2). If my understanding is correct, the third
option will even deal with the user's password having changed in that it
will automatically re-prompt providing additional value over the first
option (I have not yet confirmed this).

Due to the number of systems in use in some companies or environments, they
have adopted "single sign-on" technology, and have chosen to enforce strong
security requirements on this single password rather than tracking many
passwords. For SVN this can be of great important as the company's
intellectual property are being protected by these passwords. Worse, the
Canada and US export control regulations can be very strict, and software
components written for some customers (such as the US government) can have
much financial/contractual penalties if holes exist in the system. Storing
passwords in a key ring may be insufficient in these cases as the password
is still stored to disk, and the decryption key that the user users for
their keyring may not be as strongly guaranteed as the key it is protecting.

My first speculation here is that Subversion 1.6 provide an option to use
the "in memory" key ring, rather than the "persist to disk" default key ring
in GNOME key ring. Looking at Subversion 1.6 it looks like it would be a
simple change for GNOME keyring, provided that agreement on how to configure
this option can be obtained. This gives a good compromise between 1) and 2)
in that the password will be kept encrypted in memory for the user's
session, but not stored to disk. At its simplest, the user would be given
the ability to choose which keyring to use, and they could identify the "in
memory" key ring. This change on its own greatly increases my confidence in
ability to defend the use of Subversion within a company I work for from a
security stand point. The current users are primarily Linux, Solaris, and
Windows users. The Windows security model for Subversion satisfies me from a
security perspective. If a patch to support "in memory" key rings for GNOME
keyring were to be proposed for Subversion 1.6 and it was small, would
anybody here have objections to the patch on principle?

Next we get to the repeated sending of the password using webdav with every
single request which encourages the password (even in base 64 encoded form)
to be scribbled all over memory. I'm going to put the body of this under
performance although it also has a security component.

Performance:

Every webdav request is authorized and authenticated on its own. Recently
looking at GForge I've seen substantial amounts of complex caching being
used to try to recover performance in terms of ability to ensure that: 1)
the user is who they say they are, and 2) do they have the required access
to the repository? We've recently implemented "last request" caching due to
the number of webdav requests that Subversion generates that are all
approximately the same. That is, we look at whether the request is a "read"
or "write" request, which repository was accessed, which user did the
accessing, what their password was, and whether we last authorized them or
not. Without this cache it was performing thousands of SQL queries for basic
SVN operations. This sort of problem is often solved from the webpage using
"cookies". Instead of sending the user + password with each request, a
cookie is sent back to the client, and the client will send the cookie with
future requests. The cookie is a standard fixed life time data structure
that allows server side state to be maintained providing the appearance of a
"session" to the user. If they logged in 10 minutes ago from the same
environment, why should they need to login again?

The concept here crosses with security in that a fixed life time key can be
stored to disk rather than a user/password. The need to store a
user/password disappears, and the key becomes a "fixed time password for a
particular use".

I read threads on dev_at_subversion.tigris.org in the past (2005?) where this
was raised and the sense was that neon supported cookies but that some
opponents to the idea felt that any system that relied on cookies was broken
by design. To some degree, I am seeing this as a conclusion without merit.
That is, the proposal isn't to rely on cookies, but to allow cookies to
replace the requirement for persistent passwords and to allow complex
calculations regarding access to be cached against the session (for example,
what country is the user in? what level of technology does the US government
believe the user should be allowed to see?). If the client is a client that
can provide the appearance of a user session (as I believe the svn CLI can,
or Subclipse can), it can make its capability known to the server using a
client header and the server can generate a cookie to send the session key
back to the user. Users would need to re-authenticate once every 12 hours
per repository per user. During that 12 hour period they could operate
without a password on each operation, but still not have opened themselves
to exposing their password (where the password might grant access to other
resources such as an employee's personal records).

Support for cookies is a larger change (at least in concept) that I don't
expect to make it into Subversion 1.6 at this point. I do want to re-open
the discussion on this issue as I feel that the previous discussions closed
prematurely without merit. My challenge to the group is whether each webdav
request truly benefits from being authenticated/authorized on its own (some
might call this "RESTful") vs whether there is benefit to providing the
appearance of a session (cookies).

Please consider the number of WebDAV requests that are generated as a result
of even basic operations, and how the SVN command itself is itself a "basic
operation" that may be run dozens or hundreds of times a day by busy users.

On a separate note - analysis of 'svn log' seems to show that Subversion
generates some requests multiple times when it should already have the data
it needs from a previous request? Does SVN not perform any caching of
results even within the same 'svn' command? In one case we have a log of
where it generates the exact same three WebDAV commands twice in a row - 3
WebDAV requests turns to 6 with no intermediate writes? Is this necessary?
Are you aware of this or do you need a log to see it for yourself?

Thoughts?

Thank you for your kind consideration.

Cheers,
mark

-- 
Mark Mielke <mark_at_mielke.cc>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org