The code challenge is only one time use and has a short validity period. It is not something that is going to be stored.
For (1), we could define such transformation, but at a later time, IMHO. We are getting push back even for sha256 from developers. We need to balance the benefit and adoption. BTW, what John mentioned as Brute Force attack is not talking about this. See (3). For (2), we plan to provide some guidance in the security consideration section. We know too many developers use a bad source of random. For (3), as I understand, the salting is to stretch the search space. In your example, the original search space is very small. In such cases, I understand the value of stretching. In SPOP's case, we are requiring the original search space to be rather big. The incremental value from stretching the space using a known value seems to be minimal, if at all. We are recommending to use 256bit random. (Since we are SHA256ing, more bits does not buy us much.) If we stretch the 256 bit random string with a salt and then hash, the range of the mapping is still 256 bit space. John's comment on brute force is actually talking about this. Now that the hashing is so fast that it is faster than table lookup, attacker can effectively create a table on-the-fly. Given that, prefixing with a known string does not slow the search. On Fri Nov 14 2014 at 18:40:08 takamichi saito <sa...@cs.meiji.ac.jp> wrote: > > > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
