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