On Tue 2003-01-14 at 15:26:45 -0600, Karl Fogel wrote:
> svn-agent is not an equivalent substitute for on-disk caching. Y'all
> hang out with too technical a crowd or something, I think :-). Many
> people will not remember to start up their agents. People will not
> understand how it works. They will be confused, then they will read
> the docs and be more confused. (I know plenty of people who can't get
> ssh-agent working right. They're not stupid, they just have other
> things to pay attention to.)
>
> "Oh, Subversion itself will start the agent!" But what if one's
> already running? "It'll cache a PID file in ~/.subversion/, and
> Subversion will check there first!" And what if the machine crashes
> before that PID file has a chance to be removed? "Well, if Subversion
> tries to contact the process and can't, it'll erase the PID file and
> start a new one." So superuser could crash the machine and restart
> with a trojan horse at the old agent PID, and harvest passwords? Or
> heck, why not just replace the binary with a trojan horse in the first
> place, if you're root?
>
> In other words, this is not really any more secure than just storing
> the auth data in a ~/.subversion/ area readable only by the user (I
> hope & assume Windows per-user registries are equally secure.)
I earnestly hope you are not serious about this. If you are, I am not
sure where to start, because your basic assumptions are miles away
from the consensus of any security-related discussion I have been
involved with. No offense meant.
Although I am no security expert, I am a bit interested in that topic.
The claim you made (that a plain text password in a read-protected
file is equally secure as an encypted one which is only held in plain
in memory) sounds absurd to me. For a start, the exposure time is not
the same: The one is always available, even after you deleted it
(backups), while the other is only available while you are working
with it (the encrypted form is always avaiable, but let's hope that
the encryption is good and your passphrase, too).
You are right, if your root is after it, there is no way to stop him.
You can only try to make it harder. So using a malicious root as
argument is void, IMHO.
For example, I trust my root not to sniff memory for the data
ssh-agent stores for me. But do I trust everybody who has access to
the backups that are made of home dirs? Even after when I am gone from
that company or another sysadmin has been hired? Of course not.
If someone manages to break into your account. With plain password you
have already lost, with the encrypted one intruder has still to set up
some way to get it. And so on.
I am not done yet. There are a lot of other points I am not going into
yet. I hope you see where I am getting at, anyhow.
As a last word: I do not claim that subversion has to handle
authentication data as secure as ssh does (although I can see the case
for this) or that the complexity would be worth it. But I strongly
resent the idea that storing a plain text password would be equally
secure.
Benjamin.
- application/pgp-signature attachment: stored
Received on Thu Jan 16 01:48:35 2003