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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 07:19:37 UTC 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/4f2336e7/attachment.html>


More information about the Openid-specs-ab mailing list