Secure Origins and Strong Authentication

>From "Proposal: Prefer secure origins for powerful new web platform
features", http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0222.html:

    In systems with 2-part principals, it is crucial to strongly
    authenticate both parts of the principal, not just one part.

I'm curious about what makes the authentications strong. In the web
app model, any authority can claim to certify a resource. I'm not sure
I would consider it strong, and I would probably consider it weak. I
would consider it weak because we can't differentiate between the one
true authority versus imposters (or the one true server versus an
imposter).

In fact, when data sensitivity warrant, I often find that an
application has to be moved from a pure HTML/CSS/JS web app to a
hybrid or native application so we can ensure server authenticity and
channel integrity. We need a hybrid or native application so we can
access additional APIs, like native callbacks or delegates to provide
additional checking on the authority or server.

Personally, I would feel more conformable using "strongly
authenticated" only if we could tell the platform or the socket that
"this is the server we should use" or "this is the CA to use from our
private PKI". Alternately, the app could enforce it if the platform
provided the requisite information to the application. And a way to
verify it at the application level would also help instill the
confidence.

This, of course, requires a trusted distribution channel, and we often
have it in a corporate environment. We *might* have a trusted
distribution channel from the various App Stores, but its not clear to
me if tricks like [0] have been completely remediated at the platform
level.

Forgive my ignorance here.

Jeff

[0] Apple fixes iOS App Store man-in-the-middle hole,
http://www.h-online.com/security/news/item/Apple-fixes-iOS-App-Store-man-in-the-middle-hole-1820275.html.

Received on Wednesday, 20 August 2014 12:42:07 UTC