On Jan 7, 2005, at 11:38 AM, David Wilson wrote:
> Branko Čibej wrote:
>
>> The only useful (yes, and I do mean useful, not feasible) way to
>> implement this is by havingan agent that stores passwords in memory,
>> like ssh-agent. Then "cache_passwords=ask" could become
>> "cache_passwords=agent", and could be the default.
>
> Having an agent program for plaintext passwords is not much more
> secure than holding them on disk in the first place.
> In other words, a user with suitable priviledges can access the
> password just as easily as before.
Suitable privileges to what? It might be the case for you that disk
and memory both have the same root/admin type user, but not in other
situations, including my own. The people with admin access to the
various AFS cells on my company's intranet (which include my home
directory) do not have root access to my machine. People with root
access to my machine do not have AFS admin privileges. Speaking about
"on disk" is too general -- which disk, local or remote? The cached
passwords may be stored on a different disk (remote) than that to which
memory is swapped (local), which you also mentioned. Admittedly, the
people with root access to my machine could gain my credentials for my
AFS access. However, the AFS admin people would generally be
hard-pressed to get root access. Keeping the plaintext credentials off
something like an AFS/NFS disk is one of the reasons this issue comes
up, so my points are relevant.
> An agent program also introduces the following (especially on
> Windows): if the system pages the process out, your password will end
> up *on disk* somewhere that is *inaccessable*, so even if you knew the
> process got paged, you couldn't scrub the disk.
OS-specific techniques can often be used to prevent swapping to disk of
certain sensitive data. When possible that the sensitive data be kept
in RAM, that eliminates a class of attacks where the password can be
discovered (say by someone who must unplug your computer to steal it
and who will then attack the computer via a root compromise). There
still might be some window of susceptibility (when the password is
used, it may be copied into swappable-RAM for a short period of time),
but the desire here is to minimize exposure, not eliminate it.
> If there is to be any more discussion of agent programs, please don't
> bastardise and clone the ssh-agent design -- as it does not apply to
> passwords very well at all. I suspect if someone *really* has some
> requirement to keep plaintext passwords off-disk, then password
> authentication will be unsuitable for their environment in the first
> place.
Given your lack of imagining my case above, I don't think your
conclusions here are necessarily true either.
> There are plenty of security books out there (eg. Writing Secure Code)
> that would tell you it is a very bad thing. In my opinion, the current
> practice of the Subversion folk is the ideal one - leave the
> complicated security (certificates, public keys, encryption, etc) to
> other people *who know what they are doing*. Trying to do it in an
> ad-hoc fashion like the attempt above will only lead us down a very
> windy and dangerous path.
Security systems have to interface with the programs that use them at
some point of course. I've very glad that Subversion uses neon and
Apache to handle the my client & server certificate secured connection,
but the password for my client certificate (or a decrypted version of
the certificate) certainly has to come from somewhere. Right now I
either type the password with every svn command or it lives unsecured,
cached on a remote disk. In my case, I consider tendonitis worse than a
cached client password on a remote disk. The security people may
disagree. The available solutions may be improveable. I disagree with
your encouragement not to try.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 7 20:32:29 2005