(2014/11/15 1:03), Nat Sakimura wrote:
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.
Partially or almost No.
Space size is same, as we know.
We can have an unique searching space, if adding an unique fix value.
A)
S256 "code_challenge" = BASE64URL(SHA256("code_verifier"))
In this case of YOUR SCHEME, it is enough for the attacker to have "only
one" combinaiton table of hashed and original.
B)
S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + "client ID"))
in this case of YOUR SCHEME, attacker have to search the verifier within
the unique fixed value "client ID".
The attacker have to search an unique searching space, since the
attacker have to contain "client ID", which is using verification in the
server.
It is constraint against the attacker.
It is big difference between A and B.
"So another method that attackers use is to steal the salt along with
the hash, and then generate a new rainbow table for each salt. 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)."
wrtten in
http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html?m=1
It is not something stored or password, but for searching in hash.
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.
I agree that "The code challenge is only one time use and has a short
validity period. " from the start, and I said so.
So, the attacker can not have "code_verifier" within the attack time.
"John's comment on brute force" is not my concern.
My concern is the above constraint against attacker.
On Fri Nov 14 2014 at 18:40:08 takamichi saito <sa...@cs.meiji.ac.jp
<mailto:sa...@cs.meiji.ac.jp>> wrote:
2014/11/14 14:13、John Bradley <ve7...@ve7jtb.com
<mailto: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
<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
<mailto: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 <mailto:sa...@cs.meiji.ac.jp>> wrote:
>>
>>
>> Sorry for my poor english.
>>
>>
>> 2014/11/14 10:45、John Bradley <ve7...@ve7jtb.com
<mailto: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 <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
<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>
>>
>>
;; 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>
--
;; takamixhi saito
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
