[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature Request: clients shouldn't store auth-creds

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-01-09 21:15:50 CET

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

>> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.