[Openid-specs-ab] Request artifact

Nat Sakimura sakimura at gmail.com
Fri Apr 30 01:27:59 UTC 2010


On Fri, Apr 30, 2010 at 9:42 AM, John Bradley <jbradley at mac.com> wrote:

> The OP MUST always authenticate the user for every transaction, even if it
> is with a long lived cookie.
> It is no different than a checkid_imediate.
>

Yes. But the attack vector cannot be avoided by the fact that there is an
authentication before displaying it to the attacker.

Flow is like this.

Assumption: Attacker knows about Victim and wants to collect some more
information about him.
Attacker entices the Victim to go to an RP to do some transaction with it.

Victim->RP: Check Out with identifier_select
RP-->Victim: Redirect to OP with Artifact
Attacker->OP: Guess Artifact and make request.
OP->Attacker:  Present Username/Password etc. Authn screen
Attacker->OP: Input his Username/Password
OP->Attacker: Present confirmation screen that includes Victim's request.

Of course, Attacker cannot do any useful further processing, because it is
him who would
pay etc. for the transaction. However, some damages are done already.
(I know that this is rather esoteric and unlikely case, but still it is a
possibility.)



> I am missing the double auth part of the flow.
>

In the double auth case, the flow would be like this: (In case of POST
binding. No difference in
fundamental flow for Artifact Binding.)

User->RP: Sign-in Request
RP-->User: Redirect to OP
User->OP: Redir
OP->User: Authn req
User->OP:  Authn res
OP-->User: Positive Assertion
User->RP: Positive Assertion - Now RP knows User's Identifier.
User->RP: Use Shopping Cart
User->RP: Check out
RP-->User: Authz req for payment
User->OP: Authz req for payment
OP->User: Show Invoice form RP
User->OP: Authorization
OP-->User: Positive Assertion (payment authorization)
User->RP: Positive Assertion (payment authorization)

In this case, since the "check-out" process specifies the user identifier in
its request,
the attacker cannot gain access to it.

This is the proper way to deal with this attack, but for a lower value
things,
sufficient entropy which is larger than the authenticator the user uses may
prove to be enough.


> The user gets redirected to there OP,  if they don't already have a session
> cookie for the OP they must authenticate before confirming any attributes or
> OAuth tokens.
>
> If they have a valid session cookie and have previously granted persistent
> permission for the RP to access the attributes, then there is no user
> dialog.
>
> If the RP asks for a attribute when the user logs in and the user defaults
> to allowing the RP the attribute the RP can ask for it again later in the
> flow without popping a dialog.
>
> I however don't know that I would agree to making a payment before I
> purchased something on a e-commerce site.
>
> Am I missing something?
>

As explained above, for this "request reveal attack", the fact that there
has to be some authentication
does not act as an effective counter measure.

>
> John B.
> On 2010-04-29, at 8:31 PM, Nat wrote:
>
> The problem I would have then is the directed identity flow. For something
> that is sufficiently high value, it would usually be the case that the user
> has been authenticated before checkout, so we do not have problems. The
> question is whether we require this "double auth flow" for a lower vale
> transactions. I suspect that there would be cases where one wants to combine
> the initial authentication (use identification) and the subsequent
> authorization in one, like much if the OAuth 1.0a flow. Or us it too much a
> niche to deal as a spec?
>
> =nat @ Tokyo via iPhone
>
> On 2010/04/30, at 9:20, John Bradley <jbradley at mac.com> wrote:
>
> The attacker would need to authenticate to the OP before they are presented
> with a confirmation screen.
> That may be by a session cookie and transparent to the user.
>
> Even if it is an attribute request the OP has to be certain it has the
> correct user.  The request from a RP in itself proves nothing.
> That is why I prefer to think of the request artifact as something that
> could be public.
> Possessing the request artifact proves nothing.   If we say it is secret
> people will think it proves something.
>
> John B.
>
> On 2010-04-29, at 8:08 PM, Nat wrote:
>
>
>
> =nat @ Tokyo via iPhone
>
> On 2010/04/30, at 0:17, John Bradley < <jbradley at mac.com>jbradley at mac.com>
> wrote:
>
> Having the artifact for the artifact response be unguessable is important.
>
> For the request, if an attacker guesses the artifact they can't learn any
> information.
>
>
> If the request was a pure authentication, you probably are right. However,
> if it were an e-commerce transaction, it would not be.
>
> For example, it may be a purchase of a medication which may indicate
> certain desease. The OP may display that to the user for the consent of the
> payment etc. If the attacker can view that consent screen, it will be a
> release of sensitive information.
>
>
>
> The best they can do is use it in a authentication attempt.
>
> Given that anyone can make a artifact request to the OP for anyone else and
> get the request artifact that seems like a bunch of work for something that
> at best could be a denial of service.
>
> If I were a OP I would probably generate the request artifacts as URL
>
> eg <https://myOP.com/server1/openID?HASH=RC5_HASH><https://myOP.com/server1/openID?HASH=RC5_HASH>
> https://myOP.com/server1/openID?HASH=RC5_HASH
>
> That way I can use the URI for a database lookup if I have one server,  or
> store the request in a file at the URL in rpf format if I have a cluster.
>
> Others with clusters may want to compress and encrypt the request into the
> artifact,  I suspect normal losses compression won't be enough in some
> cases.
> You could do something custom to compress it but that is still non
> deterministic.
> Thats is why I would store the request by a hash.
>
> With most OP's using directed identity, I am guessing you are probably only
> going to store one entry per RP in a lot of cases.
>
> I think those choices are up to the OP to make.
>
> I don't think that there is a real requirement in 7.5 for the artifact to
> be unique or random.
>
> The most you can say is that it is an opaque reference to the original
> request less than 400 characters.
>
> We need precise language in 7.6 saying one of openid.artifact |
> openid.rpfurl is required.
>
> The terminology that we have used in the openID specs where we have
> multiple optional elements is not super clear if one from a set is required.
>
> John B.
>
>
> On 2010-04-29, at 2:23 AM, Nat wrote:
>
>
>
> On 2010/04/29, at 0:48, John Bradley < <jbradley at mac.com><jbradley at mac.com>
> jbradley at mac.com> wrote:
>
> Is the randomness requirement different for the request?   I think that we
> can safely assume that the request can be public.
>
>
> I am not so sure about it. For a static request, it is safe to assume that
> it is a public request. However, for a dynamic request, there are chances
> that's request contains personalized data, which may be revealed at the OP.
>
> Under such circumstances, it may be wise to use a randomized reference to
> the request, IMHO.
>
>
>
> The only randomness requirement would be to prevent an attacker from
> guessing it.   I think it would be better to only assume it is a reference
> to the request and may be used across multiple requests.
>
> Why do you think there is a randomness requirement?
>
> John B.
>
>
> On 2010-04-28, at 10:32 AM, Nat wrote:
>
> John,
>
> I am open to call request artifact as something else, but I do not think it
> is a good idea to combine the request artifact and rpfurl as the
> randomness requirement is very different.
>
> =nat @ Tokyo via iPhone
>
> On 2010/04/28, at 23:25, John Bradley < <jbradley at mac.com><jbradley at mac.com><jbradley at mac.com>
> jbradley at mac.com> wrote:
>
> Nat,
>
> One simplification to consider for 7.6 may be to combine artifact and
> rpfurl.
>
> If the OP has returned artifact that could be:
> Some internal refrence ID.
> A URL pointing to some internal reference.
> Some compressed version of the request.
>
> If we think of the value as a reference to the request then the rpfurl is
> also a reference to the request.
>
> The only difference is that one is defined by the OP and the other by the
> RP.
>
> It may be confusing for people to have two things called artifact one for
> the request and one for the response.
>
> The request could be renamed to something like request_refrence
>
> Some people may prefer them separate to make validation easier.
>
> It is not a big thing.
>
> John B.
>
>
>
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20100430/58013cce/attachment-0001.htm>


More information about the Openid-specs-ab mailing list