The question is what is the attack. Any salt added needs to be communicated from the client to the AS, so we must assume that the attacker has it.
The attacker can then a) create rainbow table using the client id or whatever is the known salt. Yes the attacker must create a new table per client. Salting is really only effective for low entropy passwords to try and slow down a rainbow table attack by making the input to the hash be higher than the that of the password on it's own. Currently attackers can generate over 4Billion SHA256 hashes per second on a single GPU card. (Thank you bitcoin) It is faster to generate the hashes than to look them up via a index. If you are generating the hash in real time salting provides no determent, as the salt is just included in the hash calculation. If the code verifier was a password rather than a 256bit random key then a hash would add value against rainbow tables. In reality finding a collision against a salted password is much easier using real time hash generation than by using rainbow tables. Using SHA256 with a short hash is not safe for passwords any more. Something like PBES2 with at-least 200 rounds needs to be used, if you want have password files from being compromised quickly if disclosed. (Yes I know people are not doing that, and hence part of the reason why passwords are no longer secure) More entropy in the code verifier adds to security eg moving to SHA512 and larger verifiers, but adding a salt to SHA256 is basically a no op when defending against modern attacks. I did originally agree with your position and wanted to HMAC the client_id to defend against rainbow tables, however I am now convinced that the attack has moved on so that is no more efective than a plain hash over a random 256bit value. John B. > On Nov 16, 2014, at 11:06 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > I am actually not convinced. Since the code verifier is 256bit random, adding > salt does not seem to help. > Salting definitely helps if len(password) << 256 bit, but ... > > > On Mon Nov 17 2014 at 11:39:07 takamichi saito <sa...@cs.meiji.ac.jp > <mailto:sa...@cs.meiji.ac.jp>> wrote: > > > (2014/11/14 13:02), Bill Mills wrote: > > Yes, "plain" is actually sufficient. The hashed value protects against > > disclosure/logging threats on the server auth server and proxies perhaps > > where the HTTPS is terminated somewhere other than the auth server > > itself, it's not actually required for the basic functionality/security > > of the mechanism. > > In the threat model of the SPOP scheme, a wiretap is in it. > > And more, the hash is not used to keep secretly in the sever/client. > > > > > > > > On Thursday, November 13, 2014 7:07 PM, takamichi saito > > <sa...@cs.meiji.ac.jp <mailto:sa...@cs.meiji.ac.jp>> wrote: > > > > > > Sorry for my poor english. > > > > > > 2014/11/14 10:55、Bill Mills <wmills_92...@yahoo.com > > <mailto:wmills_92...@yahoo.com> > > <mailto:wmills_92...@yahoo.com <mailto:wmills_92...@yahoo.com>>> のメール： > > > > > The whole mechanism relies on the attacker not having access to the > > code_verifier or hash. It's defending against the attacker getting the > > code via weakness in IPC or other such mechanism like URI handlers. How > > many more bits is secure beyond 256 bits of entropy recommended? If you > > want to make it longer then just make it longer, salting doesn't really > > help that much. > > > > > > The original value or the hashed value *should* be protected by the > > transport security, and if it isn't then the attacker could be stealing > > the original credential used to authenticate anyway. > > > > > > > Is it correct? > > You mean that we don’t need to use hash itself? Only to use plain is enough? > > > > > > > > > > > > > > > > On Thursday, November 13, 2014 5:40 PM, takamichi saito > > <sa...@cs.meiji.ac.jp <mailto:sa...@cs.meiji.ac.jp> > > <mailto:sa...@cs.meiji.ac.jp <mailto: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 > > <http://www.slideshare.net/nat_sakimura/1112-spoppresso> > > <http://www.slideshare.net/nat_sakimura/1112-spoppresso > > <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 <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > > <mailto:OAuth@ietf.org>> > > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > > > > > > > > ;; takamixhi saito > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org > > <mailto:OAuth@ietf.org>> > > https://www.ietf.org/mailman/listinfo/oauth > > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > > > -- > ;; takamixhi saito > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
