Sorry for my poor english.
2014/11/14 10:45、John Bradley <ve7...@ve7jtb.com> のメール：
> 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.
Really?
I think that there is same discussion in storing passwords with salt.
It seems to be dangerous to use hashes of fixed-range values.
>
> 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.
How quick?
Since lifetime of the code_challenge is short, it can works effectively.
>
>
> 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 agree.
Then, we should add “client ID” in code_challenge.
We can get a few more entropy, since client ID is not fixed value.
>
> I will come up with some text for the spec, as you are not the only person
> asking that question.
Thank you.
>
> 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
;; takamixhi saito
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
