2014/11/14 14:13、John Bradley <ve7...@ve7jtb.com> のメール：
> This blog post has some good background on why salting is no longer effective
> against brute force attacks.
> http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html?m=1
It is basic knowledge as you know.
If I don’t misunderstand the article, the article doesn’t say so.
"That's why it's so important to use a unique salt for each stored password (it
reduces the return on investment that the new rainbow table will provide)."
>
> More entropy in the secret is much more important.
>
> The code verifier should not be thought of as a password. It needs to be a
> high entropy key.
I can’t understand your point, sorry.
Probably, you may mix some points.
I separate points:
1) against brute-force
-> it should use iterations.
2) high entropy for the code verifier
-> it should use random generator such like Sandy Bridge's DRNG.
-> or using a longer code_verifier with more uniqueness.
3) against table, including rainbow
-> it should use salt-like string, i.e. adding client_ID
for example of simple use of hashing:
hash(1) = sip
hash(2) = asi
hash(3) = isd
hash(4) = tt!
hash(5) = ou?
:
:
if we apply 1 to hash, we can get “sip" every time.
Therefore,
if someone makes the table for the scheme, we can call SPOP table,
every person can obtain legitimate code_verifier from any code_challenge.
That’s my concern.
>
> John B.
>
>
> Sent from my iPhone
>
> On Nov 13, 2014, at 6:11 PM, Bill Mills <wmills_92...@yahoo.com> wrote:
>
>> Adding client ID is no better than simply adding extra random bits, but 256
>> is a LOT.
>>
>> Also remember that the server SHOULD:
>>
>> - only allowing a code to be tried once
>> - at a very minimum should have a severely limited number of tries for a
>> code
>> - a short time window to use a code
>>
>> Unless you can brute force 256 bits of (pseudo)random in under a minute or
>> two the code is dead. Guess wrong, the code should be dead/trash.
>>
>>
>>
>> On Thursday, November 13, 2014 7:03 PM, takamichi saito
>> <sa...@cs.meiji.ac.jp> wrote:
>>
>>
>> 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
>>
>>
;; takamixhi saito
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
