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. For one, unless
> very complicated networking is involved (eg. passing fds between
> processes), the agent program *must* release what it is securing in
> order for itself or the data to be of any use. In other words, a user
> with suitable priviledges can access the password just as easily as
> before.
Any user with "suitable privileges" can get at your password no matter
what you do, even if you don't cache it anywhere.
> An agent program also introduces the following (especially on Windows):
*sigh* ... I'm so tired of "experts" who keep guessing about what
Windows can or can't do.
> 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.
The solution to this particular problem is, of course, to store the data
in non-pageable memory, something Windows can do just fine (not to
mention that, on Windows, you can encrypt the data using a user- and
session-specific key, so even if someone else can read the memory, they
can't decrypt the data).
> 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.
So what's the alternative? Certificates and such usually require a
passphrase, too -- and if they don't, they're quite as insecure as
passwords.
>> This would be a useful thing to have, although IIRC some people
>> object to this on the grounds of it being too complex.
>
> 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*.
The trouble is, of course, that they usually don't.
> Trying to do it in an ad-hoc fashion like the attempt above will only
> lead us down a very windy and dangerous path.
"Windy" indeed. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 9 21:15:56 2005