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

Dirk Balfanz balfanz at google.com
Mon Jul 29 10:17:46 UTC 2013


On Mon, Jul 29, 2013 at 12:35 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Increasing the length of the secret is no help.
>

But that's exactly what the salt does: it increases the length of the thing
that is hashed, thus making it "many orders of magnitude" harder to find
the preimage. I still don't see why you need a salt here. If you think your
secret is too small, then create a salt, prepend that to the secret, and
call the new thing the secret. Salts make sense if the original input into
your hash function may be in a dictionary of rainbow table. Here the client
has control over the original input (it generates the secret) and can make
the probability of that occurring as small as it wants.


>
> The thing is that the password is unstructured so any string that computes
> to the same hash works.
>
> 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.
>

Wait, what? Telling me a prefix of the pre-image will make it _harder_ for
me to find the pre-image? I don't think so. If anything it'll make it
easier. What makes it harder is not that I will have to match a certain
prefix, it's that the search space is bigger with a salt (or with a bigger
secret, for that matter).

Dirk.


>
> 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
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/8d7ced00/attachment.html>


More information about the Openid-specs-ab mailing list