(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> wrote: Sorry for my poor english. 2014/11/14 10:55、Bill Mills <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>> 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>. > > 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> > 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
-- ;; takamixhi saito _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
