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
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.
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
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
