[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Cap vs. cap + password - recap
From:       Sandro Magi <smagi () naasking ! homeip ! net>
Date:       2005-11-30 1:44:16
Message-ID: 438D03F0.90401 () naasking ! homeip ! net
[Download RAW message or body]

Jed Donnelley wrote:

> At 02:15 PM 11/27/2005, Sandro Magi wrote:
>
>> 2. The browser can be an untrusted object which nevertheless holds,
>> manipulates, and displays cap-URLs. (I say 'can be' because while you
>> might trust your home computer, but you might not trust an internet cafe
>> computer) This makes it a seriously weak link in any serious
>> web-calculus app.
>
>
> Something (some software) has to be trusted to manipulate permissions
> for an active entity (e.g. a user or a process).  The final 
> transformation to
> a sensitive form can be delayed until the time of use and even then the
> transformation can be made to a form only useable by the intended
> recipient.


Yes, but the benefit of authentication over capabilities *in this 
scenario* is that the browser is "trusted" with the user's authority 
only for the duration of a session, which begins when the user "proves" 
himself to be who he claims, and ends when the user logs out or closes 
the browser.

>> 3. There are many channels over which cap-URLs can leak including, but
>> not limited to,
>>  a) browser features (cache, URL history, Referer header, etc.)
>>  b) mistyping URLs can trigger side-effects that divulge a cap-URL, or
>> enough of it to reconstruct the full one, to third parties; anything on
>> the network could potentially intercept a mistyped URL depending on the
>> circumstances
>>  c) customized attacks: key loggers, screen scrapers, over the shoulder
>> reading (I think all web apps are vulnerable to these)
>>  d) anything else?
>
>
> See above.


Even your approach is vulnerable given full CPU emulation. Of course, 
the barrier is the highest yet, and arguably the best solution that 
could probably be devised given the circumstances.

>> 4. When dealing with users, separating designation and authority is
>> slightly more secure overall than a cap-URL scheme which bundles them,
>> because in the former, credentials are held beyond the reach of
>> transmission channels, in "trusted storage" (extent of trust depending
>> on the level of confidence you have in your memory ;-)). As a natural
>> consequence of the limitations of human memory, they are easier to
>> brute-force however.
>
>
> I don't agree with the above.  In my experience such separation makes
> the actual communication of permissions (management of authority)
> more confusing and thus more prone to error and thereby less secure,
> not more secure.


I am referring only to the scenario under discussion in which the user 
is using a third-party computer. The computer cannot be trusted to 
properly manage his authority (since the browser leaves breadcrumbs all 
over the place), so the user has only himself as the trusted party.

Given USB storage, certain other solutions may help capabilities surpass 
authentication in this regard; the browser will still leak, but at least 
it will leak to the user's own USB key.

>> 5. While capability UIs in an environment with a trusted intermediary,
>> like a powerbox, are straightforward to use securely, these patterns
>> don't apply to the web because no such intermediary exists; if someone
>> could think how to arrange one, then this might resolve most of the
>> problems discussed thus far. As heinous as it sounds, I'm tempted to
>> propose using javascript to build an in-browser environment... ;-)
>
>
> Hmmm.  I'm afraid I don't understand the essence of the above #5
> statement.  Any process with the ability to access and appropriately
> transform capabilities for access and sharing is empowered as
> essentially a "powerbox".  This is by intent.  It is up to the creators
> of the user environment to limit such access to trusted software
> (e.g. plash or Polaris or whatever the user has available as a
> trusted communicator of permissions). 


Correct me if I'm using the terminology incorrectly, but I understand 
the powerbox to be an object specifically entrusted with the user's 
authority (in agreement so far). The web browser cannot be "trusted" to 
act as a powerbox, because it leaks authority. This seems to violate 
every use of "powerbox" I've seen.

In #5 I was suggesting that YURLs be fetched and manipulated via 
javascript, effectively bypassing the browser's authority-leaking 
mechanisms.

Sandro
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]