I've worked on two projects in the last 6 months where svn has been put
forward as an "option" and both times its been passed over in favor of
things like rational.
Fair enough, its been big corporates that I've been working for who value
the perceived security they get with products like rational, but both times
the same thing has happened. The project goes to get security approval for
the various options they have on the table and svn is thrown out by the
corporate security groups as an option. Both times, svnserve wasn't even
considered to be something that was going to be used, but both times the
same argument was thrown in:
"well, if the guys who code subversion are willing to have passwords kept on
the OS in plain text, how many other problems exist in their code?"
To which there is no real answer.
The sad fact is that the minimum security level is always one-way hash or
two factor auth'ing in those environments. I asked one of the guys to send
me an email about why this all comes about and his response was mostly what
I expected but he had a few points I hadn't thought of (im paraphrasing
here):
-----
We consider nothing secure (OS, software, hardware, all of it), no matter
how up-to-date anything is and no matter how isolated it is from the any
other network the potential for someone to "break in" exists (that's the
basis from which we work). Keeping plain text passwords anywhere on a system
is essentially "giving them away for free", and any hacker that managed to
get that close will see the svnserve port open and it's a red-flag for them
"hey, free passwords here". Now assuming they managed to hack into the box
(and they may not even have to do that), theres no telling what those
passwords give them access to. Obviously a certain amount of intelligence
will tell you that "a password policy is in order", unfortunately policy is
never a real answer to anything. No matter what you tell the users to do,
they almost always end up ignoring it cause its "too much hassle" unless you
can enforce it, and that's something else svnserve cant realistically do.
Even worse, if we implemented some way of checking what the user selected as
a password as not being a password they're using anywhere else, and they did
the damage has already been done. The password is now in the OS file system
somewhere, so what do you do? DOD erase the entire drive? Disable their
account across every environment we find they're using the same one? That's
an extreme amount of work considering the number of environments potentially
impacted, not to mention the waste of the person who now has to call a
helpdesk somewhere and sort the situation out (even if it was their own
stupidity in the first place). I also said they may not have to break into
the OS to get the passwords, which is the second problem with it; What if
someone found a hack (buffer overflow, remote execution flaw, etc) in the
daemon that allowed the user to just dump the password file from remote?
That's an even more troubling scenario.
Now with your project, you weren't going to use svnserve, and instead were
heading for webdav option. Considering the code that drives svn's webdav is
probably written by the same people who would put plain text passwords on
the OS, the same level of trust has to be assumed. Unfortunately that's
quite low, any developer who considers keeping plain text passwords on the
file system of the OS and relying on the OS's own security for protecting it
is living in a dream world. I can even bet you money that the daemon doesn't
even go to any lengths to protect that file (i.e. doesn't even complain if
the file is world-readable). Now if they had just made the file encrypted on
disk and force you to enter a password to start the svn server daemon to
unecrypt the file (like the way apache keeps its keys), then that's 100
times better (not perfect mind you because if you can make the daemon dump
its memory in some way you would probably still get the passwords, but at
least it's a level of security that is acceptable).
Now obviously there's a lot of software out there we use that has exactly
the same problems (for example with apache you can keep the key on-disk
unencrypted), but none of the products we use give you the potential to gain
a real-user password like a corporate lan login. But this is also why we go
through each project on a case by case basis. Considering the people who
would be using subversion in this environment are fairly "trusted" users who
have access to some very sensitive customer information, the risk is quite
large. User logins in most environments always have the largest potential
for causing damage and we do as much as we can to mitigate the risk. Sadly,
the users themselves are usually the biggest problem but we're not in the
business of adding to that risk even in the smallest possible way.
Using subversion may save you a lot of money (compared to the many dollars
you'll spend implementing rational), the project code base may even be quite
small and the code itself may be of no value to a hacker (in fact,
everything on the server running subversion may not help a potential hacker
or be of the slightest use to them). The reality of the situation is I have
to ask the question "what else could a hacker gain access to if they got
access to that password?" (irrelavent in your environment I know) but then I
have to ask "how can we trust code that would allow it in the first place?",
and the answer is you cant. We would be negligent to sign off on any project
using subversion for just those reasons.
-----
The way I read all that is simply to say that because subversion's daemon
allows this kind of behavior its sadly devalues everything that subversion
is. Sure it's a big corporate that can afford a commercial product, but its
sad to see svn pushed aside from such a small issue really.
Received on Tue Jul 18 15:03:06 2006