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
