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.
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> のメール：
> 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> 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
