Re: Can we remove the PSL dependency?

The Credential ID was not meant to be secret.  As a result, there are web
services that first collect the second factor credential and the password
before performing any authentication -- the idea being that this prevents
password brute force attacks.   But this means that the web services give
out the credential id before any type of authentication is done.  TLDR --
an attacker doesn't need an XSS to get a credential id, the attacker just
needs to have a username.

Now, as to why it's not okay to always reply (as a platform) when receiving
a request with a credential ID that is present -- it allows tracking and
linking across websites.  Imagine that the attacker owns turtles-fans.com
(also imagine that in this parallel reality, it's really awkward to like
turtles).  Now Alice has an account with email.com and turtle-fans.com.
Alice is very careful to not link the two identities.  Alice also use a
webauthn device as a second factor to both sites because she knows about
the super awesome protections that webauthn offers.  Now imagine that the
attacker suspects that Alice is actually a user of the his site.  To prove
this, the attacker gets Alice's credential id from email.com (just by
asking), then next time Alice tries to log in, the attacker uses the stolen
credential id.  An invalid assertion will get generated, but it doesn't
matter because the sheer fact of the assertion will tell the attacker that
this is indeed Alice.




Thanks!
-Alexei

*____**_**__**_**_**_**_**_**_**_**_**_*

 . Alexei Czeskis .:. Securineer .:. 317.698.4740 .

On Thu, Jul 28, 2016 at 11:38 AM, Richard Barnes <rbarnes@mozilla.com>
wrote:

> Hey folks,
>
> One of the things that's bothered me for a while about this spec is that
> it is dependent on the Public Suffix List (via eTLD+1), a technology that
> we are trying hard to deprecate.  Every other security boundary in the web
> is origin-based (except for cookies, an anti-pattern), so why not this one?
>
> Proposal: RP ID == Web Origin
>
> I understand that people want to be able to share credentials across
> origins to a degree, so that, for example, you could have
> accounts.example.com make a credential and login.example.com use it.  So
> let's operate under the assumption that if you're going to have a
> restriction on who can generate an assertion, it would need to accommodate
> this pattern.
>
> Let’s try to articulate the requirements here.  For each getAssertion()
> transaction, there’s a CreatorOrigin that created the credential and an
> AssertionOrigin that calls getAssertion().  As I understand it, the
> security requirements are then:
>
> - AssertionOrigin can only get an assertion if authorized by CreatorOrigin
> - If an assertion is generated, it is bound to AssertionOrigin (and/or
> CreatorOrigin?)
>
> The current spec provides a very loose approximation, using possession of
> the credential ID and belonging to the same eTLD+1 as a proxy for
> authorization, and using the eTLD as a rough identifer for either origin.
>
> - AssertionOrigin can only get an assertion if:
>   - It has a copy of the credential ID
>   - It is in the same eTLD+1 as CreatorOrigin
> - The eTLD+1 is included in the assertion
>
> This is pretty lame sharing model.   It unnecessarily places all
> subdomains of an eTLD+1 at the same trust level.  It forbids sharing across
> the eTLD+1 boundary, even when it's authorized.  And it only provides
> partial information about who generated the assertion.
>
> Changing to use the web origin as the RP ID would make this much more
> faithful.  With regard to indicating the AssertionOrigin in the assertion,
> using the full origin instead of the eTLD+1 obviously provides more
> information to the verifier.  The slightly more interesting question is how
> authorization gets expressed.
>
> I would propose that using possession of the credential ID is a sufficient
> signal of authorization to use the credential.  You get a pretty good level
> of protection against things like phishing just by having the credential ID
> not be accessible to unauthorized sites.  Even if an unauthorized origin
> (AttackerOrigin) can get access to a credential ID, e.g., via XSS, every
> assertion it generates will indicate AttackerOrigin as the AssertionOrigin,
> so verifiers can easily recognize incorrect ones.
>
> The sharing requirements noted above can still be satisfied even if RP ID
> == Origin.  The only modification that’s required is that the verifier has
> to check the assertion against the AssertionOrigin, instead of the eTLD+1.
> The AssertionOrigin has to get a copy of the credentialID, but it already
> had to do that before.
>
> If we want to have a more restrained sharing model than just using the
> credential ID as a bearer token, it seems like there are a few ways you
> could imagine creating an origin whitelist for a credential.  (For example,
> you could pass the whitelist into makeCredential() and have the credential
> encode it in the credentialID.)  But before we launch into designing this,
> I would want to know what the threat model is that this would address.
>
> Thoughts?
>
> --Richard
>
>