Jeremy,
Let me paint a scenario for you, and this is just one scenario that worries
people with a focus on security.
Develeper Y comes along and says "we want to use svn, with webdav". Security
sign off on it saying "so long as you don't use svnserve". 6 months down the
track the head developer, the designer and the system admin have all changed
hands. Some developer says, "you know, svnserve is a lot easier to manage"
(or some usefull argument that makes svnserve sound better than the other
options out there). Security have already signed off on the environment and
so aren't involved in either the descision to change, or the change itself
and are blissfully unaware this took place (as a side note, the people
implementing the change may not even be aware they're doing wrong either).
Step forward another 3 months and 3 serious unpatched security
vulnerabilities appear on the box cause the sys admin is just not doing
their job effectively (not to mention a bunch of other projects may have
left on the svn reposity cause its easy to do). An intruder breaks in and
the inevitable occurs, he gets the password file. He probably checks out the
code base, and maybe (just maybe) decides to nick off with some code. But
now he probably has quite a few user logins, so he checks them out to see if
they gain him access to other resources.
And THAT'S where it goes very pear shaped very quickly. If it just so
happens that developer Bob has access to a db server somewhere that stores
sensitive customer data such as credit cards, it will no longer be corporate
security that get involved, it'll be the local authorities knocking on your
door.
Then again, lets take a simpler scenario.. the svnserve daemon gets switched
on, and the system admin for the server (or anyone with access to the
server) leaves the company in a less-than-amicable situation. He has some
latitude for revenge.
Sure, theres a lot of "what-if's" in there. But keep in mind, a lot of the
reason "security" people take these stances is because scenario's like this
have already happened somewhere. Now you can sit there and say "well, this
should have happened" and "that should have happened", "the box should have
been patched.. blah blah blah", but security folk just don't take those kind
of risks in the first place.
As for clear text user credentials in cookies, well that doesn't happen in a
secure environment either. Can you imagine what would happen if your local
online bank decided, "yeah lets just stick the username and password in the
cookie cause that easy", you would be able to count in hours the time it
took for the general public to be outraged. On top of that in most countries
is just plain illegal (for a situation like a bank at least).
But, it wasn't really the whole point of the original post anyway, I was
just simply trying to point out why security especially in large
corporations think svn is a gigantic security hole.
At home, I use svnserve and webdav. Works for me. But does anyone really
care that much that some faceless corporation's not using svn for whatever
reasons? I certainly don't. From my perspective it would be kewl to be able
to say to people, "hey, company x choose svn over rational". But it really
doesn't matter.
Paul
_____
From: Jeremy Whitlock [mailto:jcscoobyrs@gmail.com]
Sent: Wednesday, 19 July 2006 3:21 PM
To: users@subversion.tigris.org
Subject: Re: plaintext passwords - my 0.02c
Stuart,
Just so you know, clear-text passwords are not the case for Windows and
will not be the case for Mac OS X as of the 1.4.0 release. Linux would
still be a problem but I don't think this is a reason not to use Subversion.
Also, you say that people don't care about this issue and apparently they do
because Windows already encrypts creds and Mac will in a few weeks when
1.4.0 is release. Linux isn't getting the short end of the stick either as
support for them is being worked on.
I really do not think that using old data to formulate a reason not to
use Subversion is not a good thing to do especially on the list. Every
point you brought up was invalid. I think there are bigger fish to fry at
whatever company you work for with managing the internet browser. Clear
text user credentials are stored in cookies all of the time and since
physical compromise is an issue to you, you might want to look at other
programs that store user credentials to complain about.
Take care,
Jeremy
On 7/18/06, Stuart Celarier <SCelarier@corillian.com> wrote:
I'm with you, Paul. Subversion *is* a hard sell to folks with 'Security'
in their job titles.
The FAQ entry on plaintext passwords is probably the single biggest deal
breaker for many serious security reviews. Read it.
http://subversion.tigris.org/faq.html#plaintext-passwords
I'm focusing solely on what the FAQ says, not whether it is correct or
up to date. Here's a summary of what it says to a cynical, paranoid,
risk-mitigation kind of guy whose job it is to say "No" -- you know the
type.
1. Trust the OS to protect the data. Sure, until the OS is compromised,
as if that never happens. These developers sound like rank amateurs on
security matters.
2. If you don't want passwords stored in plaintext, you have the option
of not storing passwords at all. Bad options lead to bad decisions:
given the opportunity to choose the lesser of two evils, people often
choose the path of least resistance regardless of the evil involved. Not
good.
3. Aw, heck, all my friends are doing it, worse actually, so what's the
problem? The fallacy here is no one said that CVS set the security
standard for Subversion to match or best.
3a. And no one cares about this problem enough to do anything about it.
If I do, I can send in a patch. It can't be easy if no one's done it
yet. And I need a version control system now, not next quarter or next
year.
Four reasons to say no; no reasons to say yes. Case closed.
I suggest that rewriting this FAQ item to be more security savvy could
go a long way to reducing the perception -- true or not -- that
Subversion developers don't take security seriously.
Stuart Celarier | Corillian Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 19 08:26:44 2006