Re: A somewhat lame Web Crypto PIN provisioning solution

On Tue, Apr 2, 2013 at 2:16 PM, Jeffrey Walton <noloader@gmail.com> wrote:
> On Tue, Apr 2, 2013 at 2:48 PM, Ryan Sleevi <sleevi@google.com> wrote:
>> ....
>>
>> If an origin does not trust itself (for example, it expects to host
>> both 'sensitive' and 'hostile' code on the same origin), then it
>> should use the same technique that sites have been deploying for the
>> past decade - separating security zones on the basis of origins.
>> Google, for example, has done this quite successfully with
>> accounts.google.com versus the rest of its domains, as have a number
>> of other large sites. This is not limited to the Web Crypto API - this
>> is a security approach fundamental to the web.
> In practice, Google violates SOP from the user's perspective. From the
> user's perspective, domain granularity (and perhaps subdomain) is what
> one has to work with.

Let's not overload the terms here.

It's exactly because of SOP that you structure things like this.

A discussion of what domains logically make up an organization is
certainly interesting, but not for here.

The point is that the technique of hosting multiple origins with
different security requirements - whether login.foo.com or
static.foo.com - is well-established. When we talk about cryptographic
keying material being tied to SOP (which is the *most* granular we can
or should get - cookie paths are a joke), then it's inherent that we
recognize that people will and should be doing this.

>
> For example, walk over to a Windows machine and add "*.google.com" and
> "*.gmail.com" to theTrusted Zone; and then try to login to Gmail.
> Login will fail because Google routes authentication through YouTube.
> For sake of argument, suppose login succeeds. Other Gmail operations
> will fail because another domain - googleusercontent.com (or similar)
> - is used.
>
> But it might make a good use case: how to handle a certificate to be
> used in a particular PKI mapped onto a domain. Make sure the case
> includes operations from another domain (in violation of SOP).
>
> Jeff

-1 to promoting alternative security schemes that deviate from SOP.

Received on Tuesday, 2 April 2013 21:27:59 UTC