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

John Bradley ve7jtb at ve7jtb.com
Mon Jul 29 07:56:03 UTC 2013


The issue has nothing to do with the hash function being compromised.

This is basic hash collision.  If the attacker has compleate controll over the text to be hashed then creating a collision is much easer, the hash function itself makes no difference.
Having a bigger hash makes the work harder but it is deterministic.    

For this taking the left half of the larger hash helps a bit, but us probably less useful than the salt in preventing collisions.

We still have the sha1 problem so half a SHA256 is still useful.  




On 2013-07-29, at 9:41 AM, Nat Sakimura <sakimura at gmail.com> wrote:

> 
> 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/32b7208b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/32b7208b/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list