RE: plaintext passwords - my 0.02c

I have been following this thread with some interest - having worked as
config manager for ten years or so, mostly with large financial
organisations and now with a much smaller firm, I can understand security
(and other!) concerns that some companies would have but also recognise that
some firms' security people can go over the top with these things.
Basically, the cost to protect (including potential lost productivity) must
be balanced against the potential loss through security issues and I guess
that both these things are very difficult thing to quantify.

However, I have this question: Is the problem limited to environments
only using svnserve?

For example, if I set up an environment using https, there are no plaintext
password files stored on the server but I still have the issue of having my
own password stored in plaintext in my own home directory
(~/.subversion/auth/svn.simple - or something like that, I think) - albeit
with read permissions only for me.

I accept that this is not as big a problem as a whole password file but if
my home directory is mounted across several machines, there's nothing to
stop somebody (who has root access on **any** of those machines) su-ing to
me and taking a peek at my passwords. In a networked environment this is not
difficult to do (getting root to a linux desktop is not difficult if you
have access to the box on the desktop!)

Can I keep this password stored in an encrypted format? Does anyone else see
this as an issue??

Cheers

Mark.

Paul J R wrote:

    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

-- 
Mark Ryan
Email: fatrascal@bigfoot.com