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
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
So what's the alternative? Certificates and such usually require a
passphrase, too -- and if they don't, they're quite as insecure as
>> 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. :-)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Jan 9 21:15:56 2005