In Windows you can set up files or directories to be encrypted, which
would mean that only the specific user could read them based on the
user's login password. I assume that if they were copied to tapes, they
would stay encrypted.
I'm not sure how Linux compares in this regard, but if it has such an
option, that would be my first suggestion.
If you wanted to keep the password off the drive entirely, I'm not sure
what you'd do, since from what I understand, you'd have to enter your
password for every Subversion command. If there's a good way to keep a
sort of "session state" (possibly through a daemon and some IPC) that
holds your password only until you logout, that might be another
solution, but it sounds like that would have to be written into the
Subversion client libraries and it might be platform-specific. I'm not
sure if you could keep the passwords out of the swap file either, though
you could at least obfuscate them in memory.
I'm no security expert though. Perhaps there are well-established ways
of solving this problem, because I doubt it is specific to Subversion.
-----Original Message-----
From: Hadmut Danisch [mailto:hadmut_at_danisch.de]
Sent: Friday, March 21, 2008 11:31 AM
To: Daniel Danger Bentley
Cc: Ryan Schmidt; Blair Zajac; users_at_subversion.tigris.org
Subject: Re: Security flaw: subversion stores passwords by default
Obviously, they should not be checked in or out as root, but as the
admin who is currently doing the job. Therefore, every admin has to
check in and out with his personal login name and passwords. Works
exactly as expected. Being root while accessing the SVN as John or Jane
Doe.
But if the passwords are stored unintentionally under /root, the next
admin could accidently use or read that password.
Another problem: If the admins or regular users write their own
passwords onto the harddisk, they would be written onto backup tapes as
well. Whoever gets access to one of these backup tapes would get the
passwords for free.
Same if an attacker managed to enter a machine: Find the passwords and
break into every other machine (although I agree that he could achieve
the same with modifying the login or svn binaries to store the passwords
somewhere else, but there's no need to make it that easy.)
Reality showed that even if you are fully aware of the problem, there's
always a machine where the config file is as it was delivered by the
linux package.
But this all boils down to a simple rule at the end of the day:
It is a really bad idea to write passwords in plaintext and without
protection into files.
And the discussion so far about trust, passwords on the wire, and so on
showed that the design is based on odd assumptions that do not hold in
common.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-21 19:04:04 CET