Regarding
> Other problem is the following, using Nat’s slide:
> http://www.slideshare.net/nat_sakimura/1112-spoppresso .
>
> 0. Attacker prepares own code_verifier and code_challenge.
> 1. replage legitimate challenge with malicious code_challenge.
> 5. Attacker can submits own code_verifier.
>
> It may be out of the draft, I think.
I think this is out of scope.
On Fri Nov 14 2014 at 10:46:07 John Bradley <ve7...@ve7jtb.com> wrote:
> We have discussed it and that was in fact my original recommendation.
> However I have been convinced that it adds complexity without any real
> improvement in security.
>
> The reality is that people don't bother with rainbow tables these days.
> They calculate hashes on the fly faster than they can look them up. If
> you are generating the hashes to find a collision then having fixed text
> that is known to the attacker won't help.
>
> It is better for people to have more entropy in the code verifier than to
> have a fixed block of text. I want to avoid people using less bits of
> entropy because they think the hmac is adding something.
>
> I will come up with some text for the spec, as you are not the only person
> asking that question.
>
> The other issue is that the term HMAC is scary to developers and we want
> maximum adoption.
>
> John B.
>
> Sent from my iPhone
>
> > On Nov 13, 2014, at 3:28 PM, takamichi saito <sa...@cs.meiji.ac.jp>
> wrote:
> >
> >
> > Hi all,
> >
> > I appreciate this idea, simple and powerful to achieve proof of
> possession.
> > But, I have some questions against the scheme.
> > Sorry if these ware already discussed.
> >
> > I worry about using a hash function in simple way.
> > I mean, a simple use of random as code_verifier may cause that malicious
> client can have any code_verifier and code_challenge.
> > All combinations of random and its hash can be obtained, it may not be
> risk?
> >
> > So, we should use:
> > S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”))
> > or
> > S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”
> + “server ID”))
> > Where, you know that client ID is client’s unique name.
> >
> >
> > Other problem is the following, using Nat’s slide:
> > http://www.slideshare.net/nat_sakimura/1112-spoppresso .
> >
> > 0. Attacker prepares own code_verifier and code_challenge.
> > 1. replage legitimate challenge with malicious code_challenge.
> > 5. Attacker can submits own code_verifier.
> >
> > It may be out of the draft, I think.
> >
> > Best regards,
> >
> >
> > ;; takamixhi saito
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
