Garrett Rooney wrote:
> On 8/21/06, Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>
>> Well, yes. But you have to say that.
>
> Umm, no, I don't /have/ to say anything.
>
>> Your statement that "It's stored with
>> permissions such that you're the only user who can read it" is
>> blatantly incorrect.
>
> No, it's not. It may be incorrect for /your/ situation, but it is not
> incorrect for the vast majority of users.
This is simply untrue. For many users, who use Windows clients and thus
apparently store them encrypted locally, it's OK. But for those many
hundreds, thousands, or perhaps tens of thousands who work in Linux or
Solaris, and who have machines with NFS home directories, unencrypted
backups, laptops, or otherwise have physical access to their machines by
people in the same encironment, it's a serious issue.
Peoiple need to be clear that it *is* a security risk, and to pursue the
extra step of enforcing ssh+svnserve access only if they're going to operate
in operating systems that do not encrypt such stored passwords. Anyone who
thinks that keeping your core security information in a personal directory
which permissions set to 700 is simply not taking the security risk
seriously. It's no better than taping your password under your keyboard.
>> Moreover, since more users are using LDAP or even NIS based
>> single-sign-on systems to manage their user accounts for Subversion,
>> it's leaving a gaping security hole that is a serious risk to using
>> Subversion by any means other than local file access, or
>> ssh+svnserve. Plain-text passwords are an old and serious security
>> problem: they shouldn't be ignored..
>
> You're welcome to come up with another solution that more adequately
> addresses your own needs. At this point, we have several options that
> don't require local caching of passwords, the ones you mentioned are
> some, others are using a win32 client (which will encrypt the data
> using your windows credentials) or in 1.4.x a Mac OS X client (the
> passwords will be stored in Keychain, similar to the state of things
> on windows). When options other than the unencrypted file present
> themselves we've taken advantage of them, if those options are not
> available to you then you can use svn+ssh:// or you can type in the
> damn password when it's needed, but don't act as if we're putting our
> heads in the sand and ignoring the problem, because there are numerous
> solutions to it around if you care enough to look for them.
Again, you're missing some risky situations. CygWin has a Win32 client: it
does not store the passwords encrypted. Only certain Win32 clients, such as
the wonderful TortoiseSVN, encrypt their stored passwords. And storing
subversion passwords on a Win32 box, unless the user's home directory is
encrypted, is a bad joke if anyone can walk up the machine unobserved for a
few minutes with a Knoppix boot CD and grab their boss's or professor's or
the TA's passwords. I like CygWin: I find it very useful. But I may have to
tell people "don't use the Subversion client in CygWin", and try to force
them to use TortoiseSVN only, because of this sort of security risk in a
Windows envornment.
Look, I'm happy with the work in general. But please don't pretend that
making a directory with "700" permissions is a secure way to store
plain-text passwords. In an increasing number of setups, Subversion is using
the user's single-sign-on password as their Subversion password, and this
puts that password at serious risk.
In fact, I'd *love* to be able to compile Subversion so that it's svn client
refuses to store such passwords. If I wrote in such a compile-time option as
a patch, could I get support for it? I'd definitely prefer to see the
clients compiled this paranoid way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 22 10:46:55 2006