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

Re: auth cache (was: svn commit: rev 5006 - in trunk/subversion: include libsvn_ra_dav libsvn_auth)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-02-22 19:07:38 CET

Greg Stein <gstein@lyra.org> writes:

> * working copy with portions from server A and server B
> * make changes to both parts
> * commit the WC
> - server A asks for a user/pass
> - auth fetches them and sends them to A
> - trundle along, commit to B
> - server B asks for a user/pass
> - auth returns the cached user/pass and sends them to B
> - um. oop. did we just send A's password to B? damn...

Sorry, I'm confused. I think I'm dreadfully ignorant of security
issues. Why is this a problem?

The whole libsvn_auth design is based around the idea of repeatedly
generating creds. Generate creds; if they fail to authenticate,
try again; repeat until out of options.

Why does it matter that we send A's password to B? Big deal, the
creds don't work, so we start asking providers to generate them
instead. We're just adding an extra 'attempt' before hitting the
real providers, which may or may not work.

Or is the real issue here that we need to treat B as a hostile server,
and assume that it will remember any bad creds we ever send it? Is
that what I'm missing?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 22 17:10:12 2003

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.