>>>>> "Karl" == Karl Fogel <kfogel_at_red-bean.com> writes:
Karl> Hadmut Danisch <hadmut_at_danisch.de> writes:
>> Just read that:
>>
>> " Trust your OS to protect data on disk."
>>
>> That's nonsense. What do they believe why passwords stored by the
>> operating system are usually hashed and salted?
>>
>> What makes them believe that exactly that OS will be in place all
>> time?
>>
>> That sort of approach is really silly. If you can't do it in a
>> secure way, than don't do it at all (at least not without explicit
>> user consent).
>>
>> The really bad thing about this is that it not just compromises
>> subversion, but can compromise the security of the whole LAN.
>>
>> Absolutely bad design.
Karl> There are three choices:
Karl> 1) plaintext passwords stored on server and client, so that
Karl> crypttext travels over the wire.
Karl> 2) plaintext travels over the wire (crypttext stored on server,
Karl> client always has to prompt -- if client doesn't prompt, then
Karl> "crypttext" just becomes a virtual plaintext)
Karl> 3) some form of public key encryption
Karl> If you are using (3), then this discussion doesn't concern you;
Karl> you can set "store-passwords" to "no" in your config file and
Karl> sleep easy. Try the 'svn+ssh://' access method, for example.
Karl> If you're not using (3), then there are obvious tradeoffs
Karl> between (1) and (2); use whichever way is best for you.
There's a bit more to the question, though.
As was already pointed out, some OSs offer a way of restricting access
to data that relies on the user password.
Another approach is suggested by how "svn+ssh" is normally used.
If you use svn+ssh by itself, you get prompted for the key unlocking
password just as often as the password prompt you get without client
password caching. In practice, many users will avoid this annoyance
by using a tool like ssh-agent (or analogous tools in packages like
PuTTY). That caches the credentials, but only in memory, not on disk,
so you're not at risk from people grabbing your disk. (You need to
avoid "hibernate" in this case, of course, and you might think a bit
about the "cold memory" attacks and how realistic they are in your
setting.)
So... it would certainly be possible for Subversion to have an
analogous scheme, where you run a tool (it might even be the standard
client) with a command that says "go into the background and be a
credentials agent for the client". That gives you the convenience of
svn+ssh with ssh-agent, without the need to set up SSH based access
control, and without plaintext on-disk passwords.
paul
---------------------------------------------------------------------
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-20 15:49:15 CET