On Thu, Nov 13, 2014 at 6:00 PM, Nat Sakimura <sakim...@gmail.com> wrote:
> 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 that this is out of scope. SPOP is designed to protect an interception of the OAuth code grant which is a known risk on some mobile platforms. With the S256 transformation it also protects against eavesdropping of the app-to-app communication channel. > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
