2014/11/14 11:00、Nat Sakimura <sakim...@gmail.com> のメール：
> 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. I agree. But we may need to add the scope or out of the scope. There is no definition of "A malicious client” in Section 1 of the draft, isn’t it? Many people can be led to misunderstand the scheme. > > 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 ;; takamixhi saito _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
