Re: auth cache (was: svn commit: rev 5006 ...)

On Sat, Feb 22, 2003 at 10:07:38AM -0800, Ben Collins-Sussman wrote:
> 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?

Partly, yes, B could be hostile. But even more likely is the path to *get*
to server B.

Concrete example:

  * server A is CollabNet's server, holding SourceCast source
    - access via https using your corporate password
  * server B is svn.collab.net, holding Subversion source
    - access via http using your svn.c.n password
  * your working copy uses svn:externals to aggregate these two

Now, you go to do a commit and enter your user/pass for CollabNet's servers.
It is nicely protected via https, all is good. Then svn goes to commit
against svn.collab.net and it sends your corporate password over the public
Internet in the clear via http:.

See the problem? :-)

On an unrelated note, I also realized that you're allocating the credential
values in the auth baton's pool. That's no good either... that pool will
just grow without bound. The caller should continue to pass a pool for the
result value. Remember: internal pools are usually bad...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org