[Openid-specs-ab] Transient Client Secret Extension for OAuth

Nat Sakimura sakimura at gmail.com
Mon Jul 29 07:41:56 UTC 2013


Inline:

2013/7/29 John Bradley <ve7jtb at ve7jtb.com>

> Increasing the length of the secret is no help.
>
> The thing is that the password is unstructured so any string that computes
> to the same hash works.
>

At that point, is not the hash function compromised already that we should
move away from it?
Below is true, but sending a salt means that you have reduced the entropy
of the secret by the length of the salt if len (salt + shorter_secret) ==
len(longer_secret).
I would rather use a secure hash function with a longer secret.


>
> If you send a literal that needs to be combined with the password by the
> server then the hash table has to not only match the hash, the string to
> produce the hash needs to start with the salt.
>
> This make brute forcing the hash may orders of magnitude harder with the
> same hash size.
>
> Honest.
>
> On 2013-07-29, at 9:19 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> Hmmm. I do not actually get it.
>
> Salting the hash is equivalent to computing hash ( randome_salt +
> fixed_secret), is it not?
> Then, like Brian says, having original secret longer and have it being
> calculated at run-time has the same effect.
> i.e., hash (long_dynamic_secret) and hash ( randome_salt + fixed_secret)
> has the same or better effect as long as
> len (long_dynmaic_secret ) >= len(randome_salt + fixed_secret).
>
> If it is a fixed secret, yes, you are right, but it is not.
>
> Nat
>
>
> 2013/7/29 John Bradley <ve7jtb at ve7jtb.com>
>
>> If it is just a hash then it can be precomputed.   Adding a random salt
>> that is hashed with the value sent to the token endpoint prevents
>> pre-computation of the hash.
>>
>> The issues are the same as with PB-KDF given that we are sending the hash
>> in the clear.
>>
>> Yes but if I am a bed person and there is no per password salt I use a
>> precomputed rainbow table and even if I don't cover the entire space
>> eventually I will find a collision if I intercept enough messages.
>>
>>
>>
>>
>> On 2013-07-29, at 8:29 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>>
>> I have thought of that, and I do not think so.
>> Adding salt amounts to expanding the entropy of the input string.
>> So, having enough bit length in the transient secret to start with has
>> the same effect.
>> Since the validity period of the transient secret is rather short, you
>> cannot do the offline attack.
>> The attacker has to have the rainbow table to start with.
>>
>> What we want to make sure is that len(tcs) > max_len(available rainbow
>> table).
>>
>>
>>
>> 2013/7/29 John Bradley <ve7jtb at ve7jtb.com>
>>
>>> Thinking about it overnight we need to also have a salt sent with the
>>> hash, to prevent rainbow tables attacks.
>>>
>>> On 2013-07-28, at 9:39 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>>
>>> As some of you knows, passing the code securely to a native app on iOS
>>> platform is next to impossible. Malicious application may register the same
>>> custom scheme as the victim application and hope to obtain the code, whose
>>> success rate is rather high.
>>>
>>> We have discussed about it during the OpenID Conenct Meeting at IETF 87
>>> today, and I have captured the discussion in the form of I-D. It is pretty
>>> short and hopefully easy to read.
>>>
>>> You can find it at:
>>>
>>> https://bitbucket.org/Nat/drafts/src/
>>>
>>> Comments are welcome.
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>  _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/be862a97/attachment.html>


More information about the Openid-specs-ab mailing list